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

>> More precisely, in this case height > max_height, so
>>
>> init_iterator (&it, w, ZV, ZV_BYTE, NULL, DEFAULT_FACE_ID);
>>
>> is called, followed by
>>
>> move_it_vertically_backward (&it, height - unit);
>>
>> which does nothing given that height == unit, so start is set to ZV.
>
> height == unit only when max_height = 1. But the same problem will 
> happen if max_height = 2 and the stuff we want to display takes more 
> than 2 screen lines, right?  In those other cases, this code doesn't "do 
> nothing".
>

Yes of course, I was commenting under the assumtion that (setq 
max-mini-window-height 1), with which this thread started.  Indeed the 
code does not "do nothing" when max_height is > 1.

>
>> What I would suggest is to add a user option to set start to BEGV when 
>> height > max_height, which is what is needed here. It would be reset to 
>> nil in read_minibuf() before calling minibuffer-setup-hook, and would 
>> be used in resize_mini_window() as follows:
>>
>> /* Compute a suitable window start.  */
>> if (height > max_height && !EQ (Vstart_display_at_beginning_of_minibuffer, Qt))
>
> First, I'm not yet convinced starting at BOB is always TRT.  For 
> example, what if the prompt is very long and takes up more than one 
> screen line?
>

I tested this.  In that case (with max_height = 1) starting at BOB is not 
a problem, because the display engine with override this and display the 
point.  The prompt will be hidden, but this is expected.  It would happen, 
say, when you are completing a file name in a sub-sub-sub-...-directory 
with max_height = 1.

>
> Second, it is not enough to set window-start to a particular buffer 
> position, we must also make sure the position of point will be visible 
> with that window-start.  Otherwise, redisplay will override the 
> window-start we set.  So, before setting this flag, the application will 
> still need some code to see if BOB is pertinent, i.e. consider the 
> resulting layout, which is something you wanted to avoid in the first 
> place.
>

Note that this case (starting display at BOB and having point outside of 
the resulting display area) is highly unlikely.  When it happens, as you 
write, redisplay overrides the window-start that has been set here, and 
it's okay if it does.

>
> And finally, if a sufficiently generic solution that doesn't require 
> external knobs can be devised, I'd prefer doing TRT automatically, 
> without imposing such non-trivial settings on the application.
>

Yes, hence my second proposal, which checks height at EOB and at EOB-1.