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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 20 Sep 2020 21:31:21 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Stefan Monnier <monnier@iro.umontreal.ca>, 43519@debbugs.gnu.org
> 
> "Set W->start to the right place to begin display. If the whole contents fit, start at the beginning. Otherwise, start so as to make the end of the contents appear. This is particularly important for y-or-n-p, but seems desirable generally."
> 
> I won't judge the "seems desirable generally", but in this case at least it is clearly not desirable, so there should be a way to do something else.

The problem is what is that "something else", exactly, and how to
specify that to redisplay in terms it can understand and follow.

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

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

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.

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.