bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Fri, 11 Feb 2022 05:42:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's not what make-window-start-visible means.  It means "if the
> > current window-start is invisible, try to find an alternative
> > window-start that would be visible, while still showing point".
> >
> > Your interpretation of the setting is simply impossible to implement:
> > the display engine cannot possibly do anything to uncover the hidden
> > window-start point without scrolling the window in some way.  So
> > _something_ that was visible before must become invisible after,
> > because we scroll the window.
> 
> I'm irritated that the newly chosen window-start can be after the
> original position.  I don't know any use case where this is useful, and
> it was only irritating whenever it happened in my test.  Is this
> unavoidable?

It isn't unavoidable, but doing something more sophisticated would
call for a significantly more complex code.  The current solution for
when this variable is set and the window-start point is invisible is
very simple: we recenter the window around point.  The recentering
method is safe, because it always succeeds, which is why it also
serves as the fallback method of finding the suitable window-start for
redisplaying a window.  The code that implements the recentering was
already there, so the introduction of this new variable boiled down to
recognizing the conditions under which we should go directly to
recentering, bypassing all the other methods.

Anything else would mean a much deeper surgery on the (already
non-trivially complex) logic of redisplaying a window, whereby we both
verify that the previous window-start is still usable, and try various
optimizations to make the redrawing itself as cheap as possible.

> BTW, why does the adjustment happen when I just move the cursor inside
> the displayed window content without causing any display change?  The
> new heuristic seems to depend on the value of `point' (I don't mean
> values that would cause scrolling the normal way).

You may be unaware, but moving point always triggers redisplay of the
window.  That eventually nothing happens on the screen except showing
the cursor at a different location is because Emacs is smart enough to
detect that nothing else needs to change.  IOW, it's not like
redisplay is being explicitly told that only point moved, and moved
slightly enough to allow the same window-start to be used, it has to
deduce that by itself.

When this new variable is set, and the window-start is hidden, Emacs
falls back on recentering the window around point.  If point is closer
to BOB than half the window, recentering will normally fail to find a
better window-start that would show point at the center of the window,
but when point is farther than half the window, Emacs will scroll the
window as result of recentering.  That's why you see the dependance on
point position.

Once again, this option was intended to be used in relatively rare
situations.  I do not recommend to set it by default, especially if
the side effects annoy you.