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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Mon, 28 Feb 2022 00:19:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In the context of redisplay, any change of the window-start point is
> > referred to as "scrolling the window".  So when you tell the display
> > engine to make sure the window-start is visible, and the last used
> > window-start isn't, you cannot at the same time ask it not to scroll,
> > because that's a contradiction.
> 
> But when I said that using the new variable makes Emacs really scroll,
> visually, not only in an abstract sense, didn't you say mean that was
> unavoidable?

I think we are having a terminological misunderstanding here.  What do
you mean by "really scroll", and how is it different from the other
types of "scrolling", in your mental model of what we are discussing?

I'm asking because it is not trivial to define "real scrolling".  For
example, suppose Emacs changes the window-start point, and then
redraws each and every screen line from top of the window to its
bottom -- do you consider this "real scrolling"?  It may well appear
to the user as scrolling, since every line moves up or down by the
same number of screen lines.

> > > And tell me that a solution without scrolling involved
> > > is not possible, and why, or why you think that scrolling is
> > > unavoidable.  You said it can't be avoided when we do something in the
> > > display engine.
> >
> > That's not what I said.  Quote:
> >
> >   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.
> 
> Recenter means actual, not only per definition scroll - right?

No, not necessarily.  Recentering in this context means Emacs
calculates a new window-start position such that the line showing
point will be centered in the window, and then redisplays the window
using that window-start position.  _How_ it redisplays the window is a
separate question -- the display engine has several optimizations it
will try to make redisplay as fast as possible, and some of these
optimizations can be considered "real scrolling" (according to my
interpretation of that term).

> > I need a more concrete proposal to answer these questions.  IOW, I
> > don't think I understand what kind of solution do you have in mind
> > here.
> 
> I didn't make one since my knowledge here in inferior.  Personally I
> would adjust window-start from a hook and call `redisplay', which is
> probably not the best solution.

The question is how would you compute the new window-start?  What
happens after that, i.e. how the call to 'redisplay' redraws the
window given a specific window-start position, you cannot control --
it could very well decide it wants to scroll the window.  It's no
accident that scroll commands in Emacs do precisely that: they compute
a suitable window-start, and then let the display engine do its job
under the restriction that it shall abide by that window-start
position.