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

[Andrii Kolomoiets]

Eli Zaretskii <eliz@gnu.org> writes:

>> I don't take the overlay text as the actual text but rather like a hint
>> or helper.  E.g. in icomplete-mode overlay text shows what part of the
>> text can be automatically completed.  Overlay text can be completelly
>> hidden and even in this case I will be able to enter the text.
>> 
>> The prompt is more important.  Imagine there are two prompts: "Selected
>> file will be deleted. Select file: " and "Selected file will be
>> opened. Selected file: ".  I certainly don't want to see only "Select
>> file:" because all the space is occupied by hints.  Hide hints but show
>> me the full prompt.
>
> That is one way of looking at this.  But it is not the only one, or at
> least it doesn't necessarily fit all the uses of the minibuffer.
>
> 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?  As I can see, Emacs by default doesn't show any hints in
the minibuffer while reading user input.  Even with the icomplete-mode
enabled, possible completions are not visible by default if the input is
empty: one must also enable icomplete-show-matches-on-no-input.

> imagine a multiple-selection question where only a finite set of
> possible answers is acceptable, and you don't know in advance what
> that set is.  E.g., this:
>
>   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.

Those completion hints are not replacing usage of the usual Emacs
completion system, but complements it, at least in the icomplete-mode.

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

>> IMO the minibuffer behavior about the prompt, the text and the overlay
>> should be: show as much text before point as possible (including the
>> prompt), then show the rest of the text (in case the point is not at the
>> end of the text) and then show the overlay text.
>
> Do you still think this is always true?
>
>> 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.
>
> 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.

> The design of that strategy assumed that text displayed in the
> mini-window is relatively short.  It is easy to break this strategy by
> using features that were never intended to be extensively used in the
> mini-window.

Yes, and I'm not really fond of those insane examples with multiline
promts.
And if it is the application responsible for keeping the prompt short,
we must be ready for long user inputs.  For example, better show me the
prompt and the default directory on "C-x C-f" rather than all filenames
in the directory.

> 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?  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).".

> Thus, a "bug" is not an appropriate name for what you are bringing up,
> and I hope you will agree that a single strategy will never be able to
> cover all the possible uses of the mini-window.

Yes, I agree.

> 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?  Or every application must use
solution provided by Gregory?

BTW, icomplete-mode is trying way too hard :)  Just found this while
playing with completing-read:

Evaluate buffer:

(icomplete-mode)
(setq max-mini-window-height 1)
(setq icomplete-prospects-height 1)
(setq icomplete-show-matches-on-no-input t)
(completing-read "Long prompt to ask user how to send this email message. By: "
                 '("Mailclient" "Smtp" "XDG-email"))

Now use C-. to switch between completion candidates.  All but "Smtp" are
hidden with just "[Matched]" printed.


In this letter I have tried to give real examples that describes my
point of view.  It would be interesting for me to know about use cases
with the opposite point of view.

Thanks!