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

[Gregory Heytings]

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

I don't understand how you came to think about something like this.  All 
examples I gave (and the example with which this bug thread started) were 
about completion candidates displayed at EOB with an overlay, and I 
mentioned icomplete and ido several times.  I never claimed that in the 
case you mention the display should start at BOB.

> > 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 the simplest case they are, in more complex cases they are not.  And 
I'm proposing a solution that would work in all cases, not just in the 
simplest ones.

Let's continue this discussion in bug#43572, where I eagerly wait for your 
comments.