bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ghe@sdf.org,  43572@debbugs.gnu.org
> Date: Sun, 27 Sep 2020 17:59:02 -0400
> 
> >> IOW, by default if scrolling was needed anyway and scroll-conservatively
> >> is not set, I'd expect "centered at point".
> > The code which implements automatic scrolling was not written with the
> > mini-window in mind.  In fact, we would like not to allow any
> > scrolling at all there.
> 
> When the window is big enough to show the whole content, I agree, but as
> soon as the buffer is bigger then we need to handle scrolling, just
> like elsewhere.
> 
> > So perhaps relying on scrolling could be fine in normal windows, it
> > will most probably do the wrong thing in mini-windows.
> 
> That's not my experience so far.  I do find that the
> `scroll-conservatively` is generally desired for the mini-window
> (whereas I don't generally like it in normal windows), but other than
> that I find (much to my surprise) that the generic scrolling code
> behaves just as well as the ad-hoc scrolling code in resize_mini_window.

Maybe it's 80% correct, but my worry is exactly those remaining 20%.
It is they that generate most of the bug reports in Emacs nowadays.
The fact that you find scroll-conservatively improve the results is
already a clear sign that the scrolling mechanism is not fit very well
for such small windows, especially when they are used for user
interaction.  And if you look at the window-display code, you will see
there several code fragments dealing with the cases of a text line
which is as tall or taller than the window, whose results are frankly
questionable, and whose only justification is that those cases "should
not happen".  What you suggest will make the probability of that
happening much higher, and in use cases where it will hurt.

And all this is even before we take the massive use of overlay strings
in some completion features.

So no, I cannot agree that your experience is evidence good enough for
allowing GP Emacs scrolling code to handle mini-window display.

> Thinking about it, maybe I shouldn't be surprised: the generic code is
> used much more often and has been tuned quite heavily over the years to
> provide good behavior is the vast majority of cases, so it's only
> "normal" that it should behave nicely in this case as well.

That is true, but it wasn't tuned to the use cases we meet every day
in the mini-windows.  We generally don't allow a window to become too
small in height, but that happens with mini-windows all the time.