From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 18:57:14 +0300 Message-ID: References: <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10619"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: spacibba@aol.com, Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , monnier@iro.umontreal.ca, Eli Zaretskii To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 17:00:17 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcsXh-0002eP-2R for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 17:00:17 +0100 Original-Received: from localhost ([::1]:42512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcsXg-00048F-3v for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 11:00:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcsVJ-0000OG-1Q for emacs-devel@gnu.org; Wed, 11 Nov 2020 10:57:49 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:53573) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcsVF-0000kz-MR; Wed, 11 Nov 2020 10:57:48 -0500 Original-Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0005.000000005FAC09F4.00004BCF; Wed, 11 Nov 2020 15:57:36 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 08:57:59 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259017 Archived-At: * Gregory Heytings via "Emacs development discussions. [2020-11-11 12:08]: > > > > And here I come to the answer to your question: for me, the bug here > > > is that the prompt is hidden in favor of the overlay text. > > > > Applications have to accept that users want their mini-buffer windows to > > show just one line. Or at most two lines. Or three ... > > > > I agree with you, except that I would not write "users want" but "some users > want". > > At the same time, applications should be given the possibility to override > the current only behavior, which starts displaying at the beginning of the > minibuffer line on which the cursor is. Applications should have the > possibility to give a hint to redisplay that, when it is possible (that is, > when users have not asked for a single line minibuffer for example) > displaying should start at the beginning of the minibuffer (= point-min). In relation to this last line above "displaying should start..." I do not agree to that detail. This may also apply to other completion packages within or outside Emacs. Normally when minibuffer is opened there can be some default and user decides if to complete or not. To put a possible match in the space where I have my input is capricious choice where user did not decide about it. I am sorry that I present maybe too many disagreements, it is not meant like that. This is only for thinking. I do not want as user for program to give me matches into space where I need to press enter to choose that match. If that is taking place then description for icomplete, ido, fido should tell that to user. Built-in completion gives me some default in the line (maybe), but it does not enter random match into the minibuffer. So as user I do not want random matches already in my minibuffer. That seams wrong. I did not even start typing. M-x (Here I can enter what I want) As if I did not start typing why it is completing? That is hypothetical question. Built-in `completing-read' does not complete for me if I as user do not want. I have to decide to press TAB to get completion. Not one time, I have to decide normally 2 times. So it is very explicit completion that does not disturb user. Any completing package should not coerce user with matches. It shall by default leave to the user option to write in the minibuffer what user wants. This may not match, but user shall be left free to write. M-x icomplete-mode "Icomplete mode disabled" C-x C-f (no completion shown, just some default) and I can write what I want, only if I press TAB two times I can complete. M-x icomplete-mode "Icomplete mode enabled" C-x C-f shows BUNCH OF UNRELATED FILES that I have not choosen neither wanted to be shown in my minibuffer. Minibuffer is disturbed and mode line jumps up. M-x helm-find-file Window splits Minibuffer says: Find files or url: /home/data1/protected/tmp and I can write anything in the minibuffer. Program does not coerce me with files not related to my choice on the place where I should maybe press enter. That this is dangerous have been shown in bug report where files can be accidentally deleted when using ido-mode.