[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Support "\n" in icomplete-separator
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH] Support "\n" in icomplete-separator |
Date: |
Fri, 13 Nov 2020 10:39:15 +0200 |
> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> 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.
- Re: [PATCH] Support "\n" in icomplete-separator, (continued)
- RE: [PATCH] Support "\n" in icomplete-separator, Drew Adams, 2020/11/11
- Re: [PATCH] Support "\n" in icomplete-separator, martin rudalics, 2020/11/11
- RE: [PATCH] Support "\n" in icomplete-separator, Drew Adams, 2020/11/11
- Re: [PATCH] Support "\n" in icomplete-separator, martin rudalics, 2020/11/12
- RE: [PATCH] Support "\n" in icomplete-separator, Drew Adams, 2020/11/11
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/11
- Re: [PATCH] Support "\n" in icomplete-separator, Andrii Kolomoiets, 2020/11/12
- Re: [PATCH] Support "\n" in icomplete-separator,
Eli Zaretskii <=
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/13
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Stefan Monnier, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Eli Zaretskii, 2020/11/16
- Re: [PATCH] Support "\n" in icomplete-separator, Gregory Heytings, 2020/11/17
- Re: [PATCH] Support "\n" in icomplete-separator, Stefan Monnier, 2020/11/17