bug#23098: 25.0.92; (recenter -1) can leave point in the middle of the window

[Eli Zaretskii <eliz@gnu.org>]

> From: Jorgen Schäfer <jorgen.schaefer@gmail.com>
> Date: Mon, 28 Mar 2016 13:10:23 +0000
> Cc: 23098@debbugs.gnu.org
> 
> As an end user, I expect `recenter-to-bottom' to cycle the line with point on it between the top, middle and
> bottom of the current window. The problem described in this report means that Emacs does not actually do
> this – the line with point on it does not ever go even near the bottom of the window.

You are judging what Emacs does by the end result: since the result is
not to have point near the bottom, you deduce that Emacs didn't even
try.

But that is false.  What actually happens is that Emacs did try to do
what (recenter -1) requested, except that the display engine found
that doing so would have ended up with point being outside of the
window.  Since this is not acceptable, the display engine gave up and
recentered point in the window instead.

> There is a technical reason for this problem: Emacs can not, actually, display a multi-line overlay only partly.
> This is a shortcoming of Emacs, but I assume this is non-trivial to fix. When Emacs notices it can not fulfill a
> scroll request, it will use a fall back algorithm.

Yes.

> When I, as a user, try to display a line at the bottom of a window, it would appear to me that trying to keep the
> line as close to the bottom as possible instead of the middle of the window is a better fall back.

The problem is discovered at redisplay time, by some generic code that
has no direct relation to recentering, it gets run any time some
command requests that display of a window starts at a specified
position.  The fallback you'd like is more expensive, so using it in
that code would punish users who don't bump into this use case and
don't care about it.  Setting scroll-conservatively is the way to tell
Emacs you are generally prepared to deal with more expensive
(i.e. slower) redisplay if that gives you more accurate scrolling.
That's why, when scroll-conservatively is set to a large value, the
display engine does try a more accurate (and more expensive) fallback.
But doing that always, without the user's say-so, would be a
misfeature, I think.

> Setting scroll-conservatively to a large value is a way for the user to work around this behavior. But this
> workaround also affects all the other times a user tries to scroll the buffer. So this is not a fix, it's a
> workaround with unintended and rather large side effects completely unrelated to this.

I actually don't understand why you don't want to set
scroll-conservatively globally.  From what you say, it sounds like
that variable is exactly what you want, and not only in this
situation.  Can you explain why you don't see that as a solution?

> A similar problems exist for programmers trying to implement a specific behavior in buffers without
> prescribing to users how their normal scrolling behaves.

The idea is that users who are bothered by such use cases are expected
to like the effect of scroll-conservatively everywhere.

> This situation strikes me as an issue Emacs could address.

I'd welcome patches to try to fix this, but I think the best fix is
inside 'recenter': it should detect this situation and behave as if
its argument was modified so as not to request redisplay of the window
with window-start point that will cause recentering of point.  For
example, in the test case you presented, 'recenter' should behave as
if it was called with an argument of -2, not -1.

The tricky part is to implement a strategy that will do reasonable
things when the overlay or display string takes more than one line:
depending on the original value of the argument to 'recenter',
sometimes you'd want it increased, and sometimes decreased.
Interested?