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: Sun, 20 Sep 2020 18:40:15 -0400
> 
> > There's no horizontal scrolling.
> 
> To the extent that window-start is not at BOL, I think this qualifies as
> horizontal scrolling, but maybe horizontal scrolling has a more specific
> meaning within the redisplay with which I'm not aware.

We do have horizontal scrolling in Emacs: when lines are truncated.
See auto-hscroll and scroll-left/right.  That's what "horizontal
scrolling" means to me in the context of Emacs.

> Hmm...  I think I'm beginning to see where the difficulty might be
> coming from, but it's still quite fuzzy.  In my mind I'd have expected
> the code to work more along the lines of:
> 
>     - compute the number of screen lines required for displaying the
>       mini-window
>     - enlarge/shrink the window accordingly
>     - rely on the usual redisplay code for the rest (which may decide to
>       change window-start in order to keep point within view, but in
>       our current example(s) wouldn't need to do that).
> 
> 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.
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.

More generally, since the mini-window is usually small and user
interaction requires to make sure the user sees the important parts of
the buffer text (if not all of it), we want tighter control on what
will end up on display, and the way to do that is via setting
window-start.

> IIUC the problem only shows up because of the auto-resizing of the
> minibuffer window, right?
> Indeed if I replace
> 
>     (setq max-mini-window-height 1)
> with
>     (setq resize-mini-windows nil)
> 
> the problem doesn't appear, even though resizing is in fact disabled in
> both cases.

Disabling resize-mini-windows means the mini-window is not resized at
all as part of redisplay.  It doesn't mean the mini-window will always
be a single screen line.  The user or a Lisp program can resize it "by
hand", and it will stay that way until manually resized again.
Basically, disabling this means either the user doesn't care about
what will be visible in the mini-window, or a Lisp program takes the
responsibility of resizing the mini-window as needed.

When resize-mini-windows is disabled, we always start the display at
BOB.  That might be the desired outcome in the particular case you
used as the example, but as I wrote elsewhere, I'm not at all sure
this is TRT for all of the use cases we are discussing: for example,
what if the prompt is longer than a single screen line?  Worse, with
the stuff to display in the mini-window long enough, leaving the
mini-window not resized will obscure large portions of that stuff, so
this cure sounds to me worse than the disease.

And besides, this is a user option, so having some code disregard it
is unfriendly, to say the least, even if we do that temporarily.