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

[Gregory Heytings]

> I believe using window-text-pixel-size (which I already mentioned 
> several times) will avoid any such difficulties, since that function 
> takes all of those complications into account.  Therefore, I still don't 
> understand why this approach is not being explored more actively.

This I don't know or understand either.  My guess is that creating a 
candidate list by adding one candidate at a time and checking with 
window-text-pixel-size if the result is too large would be inefficient. 
This could be improved with a kind of binary search of course.

> > it is true that in all of these situations starting the mini-window 
> > display at BOB would do the right thing.
>
> Are you sure?  What if the prompt is longer than a screen line (i.e., 
> the prompt itself is continued on the 2nd and subsequent screen lines)? 
> If the prompt is long, but the list of candidates is short, starting the 
> mini-window display at BOB might fail to show some or all of the 
> candidates, because the long prompt uses up most or all of the 
> mini-window screen estate.

Yes I'm sure.  In the case you mention indeed some candidates will not be 
displayed, but that's not a problem because most of the time all 
candidates are not displayed anyway.  Of course there is the case when the 
prompt is, say, two characters less than the mini-window width, in which 
case no candidates will be displayed (if the user has (setq 
max-mini-window-width 1)), but this is unlikely to happen, and the default 
value of max-mini-window-width is 0.25 anyway.

> > > IOW, the basic logic is to show the last max-mini-window-height screen 
> > > lines of what's in mini-window.
> >
> > Yes, and this is not desirable in certain cases, it should be possible 
> > to show the *first* max-mini-window-height screen lines of what's in 
> > mini-window.
>
> Showing the last part is in general a better strategy in the use cases 
> relevant to the mini-window, which are about user interaction.

In general yes, but not when displaying completion candidates with an 
overlay at EOB, with the point before the overlay text.  In that case you 
start with a blinking cursor at the top left of the minibuffer, without 
any indication of what you are doing or should do.

> I believe you assume that starting at BOB still shows enough of the text 
> to allow the user to interact intelligently, but those are not the only 
> cases we should keep in mind, since the prompt doesn't have to be short 
> enough for that assumption to be true.

I tested this, and it works, even with overlong prompts.  In that case 
(for example with (setq max-mini-window-width 1) and a prompt wider than 
the mini-window width) the prompt disappears, but this is expected, and 
it's a corner case that almost never happens.  Moreover when displaying 
completion candidates you don't start with a long prompt (except, again, 
in corner cases).