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: Tue, 10 Nov 2020 23:09:03 +0200
> 
> >> (defvar o (make-overlay 0 0 nil t t))
> >> (minibuffer-with-setup-hook
> >>     (lambda ()
> >>       (set (make-local-variable 'face-remapping-alist)
> >>            '((default :height 1.3)))
> >>       (move-overlay o (point) (point) (current-buffer))
> >>       (let ((text (mapconcat
> >>                    #'identity
> >>                    '("Some" "text" "that" "will" "not" "fit"
> >>                      "the" "minibuffer" "window")
> >>                    "\n")))
> >>         (put-text-property 0 1 'cursor t text)
> >>         (overlay-put o 'after-string text)))
> >>   (read-string "Multiline\nprompt: "))
> >> 
> >> Is it possible to make the prompt visible?  Should I file bug report
> >> for this?
> >
> > What is the bug here?
> 
> 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: 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?

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.

> The point is more important than the prompt, obviously.  I must see
> where and what I typed.

That is a non-issue, since Emacs always shows point.

> 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.  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.  But those uses don't invalidate the design assumptions,
they just demand support for very different use cases.  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.

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.