bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content

[Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> For example, with (setq icomplete-separator "\n"), after M-x a the 
>> contents of the minibuffer is displayed as follows:
>>
>> {rp
>> lign
>> propos
>> sm-mode
>> <... other candidates, one on each line>
>
> Does the entire list of candidates fit in the (enlarged) mini-window in 
> that case? or are some of the candidates not displayed due to lack of 
> space?
>

The list of candidates is in this case (with emacs -Q) 32 lines long 
("{rp" on the first line, ... "...}" on the last line).  With (setq 
max-mini-window-height 32) the M-x prompt is displayed, with (setq 
max-mini-window-height 31) it isn't.

But the point is that there is clearly enough horizontal space, so there 
is (or there does not seem to be) no reason to scroll horizontally.

>> After pressing C-b (or <left>), the prompt becomes visible, and the 
>> minibuffer is displayed as follows:
>
> C-b moves point from EOB to a character before EOB, thus the difference 
> (AFAIR).
>

Yes, I know what C-b does, what I find surprising (but perhaps it is not, 
I'm not an expert) is that only one line (the one with the prompt) is 
scrolled horizontally.

[taken from emacs-devel:]
>
> You are asking the display engine to do the impossible.
>

No.  With a minibuffer-only frame, the bug is not present.  Whatever the 
value of icomplete-separator (that is, with either a horizontal or 
vertical list of candidates), you do see the "M-x" prompt and the 
characters typed so far, even with (setq max-mini-window-height 1) and a 
one line minibuffer.  So it's feasible, and the display engine knows how 
to do it.