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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 43519@debbugs.gnu.org
> Date: Mon, 21 Sep 2020 13:25:01 -0400
> 
> >> Do you know why we don't do it this way, IOW why don't we first try to
> >> keep window-start unchanged and see if point ends up within view?
> > Because this way we have no control on where the mini-window's display
> > will start, and consequently what will be visible in the mini-window.
> 
> Indeed, then we'll just rely on the "generic" behavior, which is
> admittedly not focused on single-line (or few lines) windows, but at
> least in the current case it works better (and simplifies the code
> slightly).

I believe the "works better" part is only guaranteed if
max-mini-window-height is 1.

> > In particular, if point is at EOB, redisplay could (and normally does)
> > decide not to position point on the last screen line of the window,
> > which means we may have some of the text not visible for no good
> > reason -- not a good thing when user interaction is concerned.
> 
> Not sure I understand what you mean.
> If point is at EOB, redisplay will make sure EOB is visible.
> 
> Or do you mean a situation like:
> - minibuffer holds "foo\n"
> - the mini window is a single line
> - point is at EOB
> In which case we'd end up displaying the empty line instead of display "foo"?

Something like that.  More generally, assume the text to be displayed
in the mini-window is

   111111111111111111
   2222222222222222222222
   33333333333333333333
   444444444444444444444

With point in the 4th line and max-mini-window-height = 4, there's no
guarantee that we will see all the 4 lines, we could see just 3 and an
empty 4th one.  Which means the user is shown only part of the stuff
for no good reason.

> AFAICT our ad-hoc scrolling code gives the same result as the generic
> scrolling code in that case.

Not sure what ad-hoc scrolling code you allude to here.  If you mean
what resize_mini_window does, then it doesn't really scroll, it just
instructs redisplay to use a particular buffer position as the
window-start; if that position makes point visible, redisplay will
comply, and we get what we wanted: we show in the mini-window what we
want to show, instead of leaving that to redisplay's whims.

> I've been trying out the patch below and haven't bumped into any
> surprising behavior yet, but admittedly, I probably lack creativity.

IOW, you leave it entirely to the generic window-display code to
select window-start based just on the value of point?  And only when
the mini-window cannot be enlarged enough?  I wouldn't.