From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Fri, 13 Nov 2020 10:39:15 +0200 Message-ID: <835z69y7kc.fsf@gnu.org> References: <20201105235735.oxouuek66ehu5o45@Ergus> <20201106151541.dpgep7borlja25su@Ergus> <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> <834klv26vu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13048"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Andrii Kolomoiets Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 13 09:40:28 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 1kdUdA-0003Jc-K0 for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 09:40:28 +0100 Original-Received: from localhost ([::1]:46692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdUd9-0001kF-M7 for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 03:40:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39760) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdUcH-0001DB-2K for emacs-devel@gnu.org; Fri, 13 Nov 2020 03:39:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43398) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdUcG-0001Wq-Ds; Fri, 13 Nov 2020 03:39:32 -0500 Original-Received: from [176.228.60.248] (port=2743 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdUcF-0002bf-PJ; Fri, 13 Nov 2020 03:39:32 -0500 In-Reply-To: (message from Andrii Kolomoiets on Fri, 13 Nov 2020 00:51:25 +0200) 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:259125 Archived-At: > From: Andrii Kolomoiets > Cc: spacibba@aol.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca > Date: Fri, 13 Nov 2020 00:51:25 +0200 > > > First, the overlay text is not just a "hint": sometimes it is very > > important to let you know what to type next. For example, the list of > > files in a large directory that are completion candidates is very > > important to see, unless you know in advance what file you want. > > Moreover, in some cases those "hints" are the _only_ way of knowing > > what inputs are acceptable: > > Can you please show me the example of such usage in the default > configuration? emacs -Q M-x icomplete-mode RET C-x C-f > As I can see, Emacs by default doesn't show any hints in the > minibuffer while reading user input. We are not talking about the default completion in this thread, we are talking about icomplete-mode and its ilk. They work differently, and in particular do show completion candidates automatically in the minibuffer. > Even with the icomplete-mode enabled, possible completions are not > visible by default See the trivial example of the contrary above. > > Send this email message by: {Mailclient, Smtp, XDG-email} > > - - - > > > > Without seeing the possible answers, what are your chances of knowing > > what to type? > > Chances are pretty good: I'll press TAB to see the *Completions* buffer. Pressing TAB seems to be against the philosophy of icomplete, ivy, and similar features, at least AFAIU: they display the candidates without any prior request by the user. > > OTOH, sometimes the prompt is not important: when you yourself invoke > > the command that prompts. For example, if you type "C-x C-f", how > > important is it for you to see the "Find file" prompt? Probably not > > too important. > > Next to "C-x C-f" is "C-x C-d", so if you accidentally hit the "d" > instead of the "f", the prompt is the only one who can tell you why no > files are showed in the completion hints. For me the prompt is > important. Sometimes I hit "C-x v d" instead of "C-x C-f" and try to > complete filename to find. You are just confirming the point I want to make: that sometimes we want/need to see the beginning, and sometimes we don't. IOW, that there are examples from either class doesn't mean one of the two classes is invalid or not interesting. > > The strategy Emacs uses to display stuff in the mini-window is shared > > by both minibuffer and echo-area display -- in the latter case your > > proposal that distinguishes between the prompt, the rest of the text, > > and the overlay at the end, will not necessarily make sense. > > Oh, in this case let's try even simpler approach: show as much text > before point as possible. What is "this case"? If "this case" is limited to echo-area display, then it cannot be shared with minibuffer display. If you mean both use cases, then "displaying as much as possible before point" will yield sub-optimal results for minibuffer input, when some text is displayed after point, whether as an aoverlay string or not. > > But those uses don't invalidate the design assumptions, they just > > demand support for very different use cases. > > Then I have a question about the display strategy: why is the tail of > the message is more important than the head? It is based on heuristic, and assumes the default values of the variables. It also assumes that the mini-window is not used to show too much stuff. > For example, evaluate this buffer: > > (setq max-mini-window-height 1) > (set-frame-width nil 77) > > Now move point to the "max-mini-window-height" and wait to eldoc message > to come up. > What I see in the echo-area is "fer and the echo area).". Yes, with radical enough customizations of the defaults, the results could be disastrous. However, the above could arguably be seen as a bug in ElDoc: it should arrange for the mini-window to be configured properly to show the info, or perhaps use the mode line in this case. > > The conclusion, IMO, is that the application should tell the display > > engine how it wants to display the stuff in the mini-window in the > > "unusual" cases, where the default strategy produces sub-optimal > > results. > > I see many applications are trying their best to fit the text into the > miniwindow. Can the display strategy be changed to display the > beginning of the text by default? We can do that, but I don't think it would be TRT, because the current strategy does work in many use cases. I thin a better way is to let applications control this aspect of the behavior, because we will never be able to find a solution that always works, what with all the different settings and kinds of display in the mini-window.