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

>
> Are you saying that the behavior before the change was better than the 
> behavior after it? Before the change you saw some part of the directory 
> name (not necessarily all of it, depending on how long the directory 
> name was), and none of the prompt.  After the change you see the prompt 
> followed by some part of the directory name (the part shown is, of 
> course, smaller than in the previous behavior).
>

I'm not judging your change by my standards, I'm judging it by your 
standards.

You explained that my proposal was unacceptable because a change with 
which no completion candidates are displayed where completion candidates 
would have been displayed without the change, is unacceptable.

>
> Displaying long stuff in a mini-window that is forced to be small will 
> always present some problems, no matter what we do.
>

Indeed, this is exactly what I said, and you replied that I was 
"disregarding" these problems.

>
> The best solution is to fit the stuff to be displayed to the dimensions 
> of the mini-window, but that is something only a Lisp program which 
> triggers the display can do, the display engine cannot.
>

In general I don't know, but for the usecase with which this bug started 
(namely displaying completion candidates after point with an overlay), the 
answer is clearly and definitely no.  The best solution is not to fit the 
stuff to be displayed to the dimensions of the mini-window, the best 
solution is to put a too large overlay at EOB and request that the display 
starts at BOB (and not at BOL as your change does, because this means that 
the prompt and user input so far can disappear, which is 
counter-intuitive).