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

[Andrii Kolomoiets <andreyk.mad@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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.

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.