Re: [PATCH] Support "\n" in icomplete-separator

[Eli Zaretskii <eliz@gnu.org>]

> 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.