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]

> Date: Fri, 25 Sep 2020 10:14:47 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: 43572@debbugs.gnu.org
> 
> >> In fact these changes are, IMO, very regrettable, because they solve 
> >> 95% of the problems that have been discussed in bug#24293, bug#39379, 
> >> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will 
> >> have to be solved another way (by text properties if that's what you 
> >> agree on with Stefan).
> >
> > They solve the issue pointed out by Stefan in bug#43519.  That they, by 
> > sheer luck, also solve some of the other issues is just that -- sheer 
> > luck.  I don't claim and didn't intend to solve all the problems, in 
> > particular the issue discussed in this bug report.  They are related, 
> > but different issues.
> >
> 
> There have been several misunderstandings in these discussions.  In 
> bug#43519, Stefan pointed out an issue with a simple recipe to exhibit a 
> more general problem.  This simple recipe, because it was simple, did not 
> demonstrate all aspects of the problem.  In particular, it only 
> demonstrated what he called "horizontal scrolling", when the problem in 
> fact involves both horizontal _and vertical_ scrolling.

I'll leave it to Stefan to say what he meant, but here's my
understanding: the problem Stefan complained about in bug#43519 was
only what you call "horizontal scrolling", and he complained about it
because that didn't happen with text that came from a buffer (as
opposed to text from an overlay string).  This is the part that I
fixed.

What you call "vertical scrolling" happens with both buffer text and
overlay strings, and is the subject of this bug report.  It's a
separate issue.

> As you see, the point is to keep the prompt visible, not just to avoid 
> horizontal scrolling.

The prompt cannot always be kept visible as long as we display the
last portion of the text in the mini-window.  The code is explicitly
designed to enforce this, so it is not a bug, but the intended
behavior.  You suggest in this bug report to add a feature that allows
to change that policy.  But that is an issue separate from bug#43519,
and thus not directly related to the changes I installed to fix that
bug.

> And Stefan refers to bug#24293 and bug#39379, where the same problem
> (the prompt becomes invisible) is explained and workarounds are
> discussed.

I disagree that it's the same problem.  Part of what is described
there is the problem fixed in bug#43519, the other part is the
intended behavior.

> > Reverting those changes would be a very strange thing to do.  Those 
> > changes solve a specific problem, and they solve it cleanly.
> 
> They partially solve a specific problem.  This specific problem exists 
> only in the context of inserting completion candidates at EOB with an 
> overlay.  And the specific problem is not horizontal scrolling, the 
> specific problem is the prompt that becomes invisible.  I clearly said 
> (and explained) in bug#43519 that to solve that problem it is necessary to 
> start display at BOB, and you preferred to implement a change that starts 
> display at BOL.  I think these changes are misleading.

And I disagree, as explained above.  So let's agree to disagree,
because these back-and-forth messages, where we both say the same
things over and over and over again, are already too many to be
useful.