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

[Gregory Heytings]

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