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

[Eli Zaretskii]

> Date: Tue, 22 Sep 2020 20:06:27 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org
> 
> 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.

This is a misunderstanding: I was talking about the cases where the
text in the mini-window comes from buffer text, not from an overlay.
The simplest example of what I was talking about is what 'message'
does when it shows a very long message, too long to show in the
mini-window in its entirety.  In that case, Emacs after the change
still behaves as I described: it shows the last portion of the text.

But this is impossible to achieve with overlay strings, because Emacs
is unable to start a window's display in the middle of an overlay
string.  It can only start it either at the string's beginning, or
after its end.

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

In the simplest case, where there's a single overlay string at EOB,
these two are identical.  In a more complex use case, where there are
multiple overlay strings, perhaps interspersed with buffer text, the
behavior now is more in line with the previous one, in that it shows
the last portion of the text.