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

[Gregory Heytings]

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