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

[I send this email again, apparently it was not delivered.  I apologize if 
you receive it twice.]

>
> My summary of the problem raised by Stefan:
>
>  . icomplete is just an example that exhibits a more general issue
>  . the more general issue is that the display after resizing the
>    mini-window is different depending on whether it uses plain buffer
>    text or an after-string overlay at EOB
>

I don't understand how you came to understand things in that way, but this 
is neither the meaning of the bug title "Overlay at end of minibuf hides 
minibuf's real content" (real content = non-overlay part), nor what was 
discussed in emacs-devel.  A short summary:

Ergus: [To implement icomplete-vertical] we need to add the exact amount 
of lines as accurate as possible.

Stefan: I *strongly* recommend you design the behavior under the 
assumption that it's OK if there are a few more lines in the (mini)buffer 
than are actually visible.

Me: if there are too many candidates the prompt disappears, leaving the 
cursor at the beginning of the minibuffer, which is counterintuitive.  A 
simple example: after (setq max-mini-window-height 1), with "M-x a" the 
"M-x" prompt and the "a" disappear.

Stefan: That can (and should) be fixed without having to reduce the number 
of candidates inserted in the (mini)buffer.

Ergus: It will be great if you give me an idea about how to do that.

Stefan: You need to figure out why the redisplay decides to hide the 
prompt rather than some other part of the (mini)buffer.

Stefan files this bug.