bug#44070: 28.0.50; Minibuffer display "jumps" upon minor edit

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 44070@debbugs.gnu.org
> Date: Sun, 01 Nov 2020 13:59:35 -0500
> 
> >> Also, I'm not sure that's what we want to do: as I argued in my previous
> >> message, this change is mostly meant to better fit the behavior of
> >> resize_mini_window, and that behavior applies to all mini-windows,
> >> regardless if they're used for a minibuffer or something else.
> > My line of thinking was that, while in minibuffers we usually want to
> > see the end of the text, that is not necessarily true in echo-area
> > messages.
> 
> Yet, that's what `resize_mini_window` does for all mini-windows
> regardless of it's an echo-area or not.

Resizing is one thing; which part of partially displayed text to show
is another.  They aren't the same decisions.

> Also, my patch shouldn't affect whether we "see the end of the text", so
> maybe I just don't understand what you're referring to.

Where do you think point is in an echo-area buffer?

> >> I suggest we keep the code as is for now, and we'll consider what to do
> >> *if* someone encounters a regression (which, for all we know, could
> >> also affect the minibuffer case).
> > Then let's leave a FIXME comment about this in those two places where
> > you use MINI_WINDOW_P, okay?
> 
> I thought the test of `scroll_minibuffer_conservative` played this role.

That's exactly why we need a FIXME: the variable says "minibuffer",
but the code checks for mini-window.

Anyway, I can add the comment myself; no need to argue.