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

[Eli Zaretskii]

> Date: Tue, 10 Nov 2020 19:17:30 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Andrii Kolomoiets <andreyk.mad@gmail.com>, spacibba@aol.com,
>         monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> (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?
> 
> The "bug" is that the word "Multiline" is not visible, only the word 
> "prompt:" is.  This has been discussed again and again, I don't understand 
> why it is not yet clear for you.

I asked Andrii.  I'm not sure if he thinks the same as you, but in
case he does: the text inserted into the minibuffer doesn't fit.  So
in this situation, Emacs can either (a) start display from the
prompt's beginning, or (b) end the display at the end of the text, or
(c) start display somewhere in the middle, to show the end of the
prompt and some of the text after it.  Whatever Emacs does, some of
the text will not be visible.  How should Emacs know which of the
possibilities is the correct one in this case?

A "bug" is when there's an obvious choice between the possible
outcomes, but Emacs behaves not in the obvious way.  I don't think
this is the situation here.  Thus my question.