bug#18739: 24.3; Request for a hook to be provided when scrolling will move the cursor

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 15:28:23 -0400
> 
> >> So, could we say that this hook is supposed to be run if and only if
> >> the window-start marker is changed?
> > I don't think so, because set-window-buffer and split-window-internal
> > run the hook unconditionally, i.e. they don't check whether the
> > window-start changed.
> 
> If the marker used to point into another buffer, it is clearly changed,
> so the only problem is that the hook may be run a few more times than
> necessary, e.g. if you set-window-buffer to the buffer that's already
> displayed in that window.

Those few more times are in direct contradiction to the definition you
suggested.  If you don't care about that, what would be the purpose of
the definition?

> >> E.g. it is not called if the only change is that text has been
> >> inserted before window-start (hence the numeric value of
> >> window-start would be changed, but the marker still points to the
> >> same place).
> > As long as the old window-start is valid and point is in view, I don't
> > think the hook will be called, no.
> 
> Good.  Consistent with my definition.
> 
> > But note that inserting text before window-start could cause
> > scrolling, if window-start was originally in a continued line, or if
> > text was added at the beginning of the line that was the window-start.
> 
> Right, in which case window-start would be modified by the redisplay in
> order to perform the scrolling and window-scroll-functions would be run,
> right?  So, again, consistent with my definition.

Sorry, I'm lost.  I no longer understand what "consistency" is being
praised here.  For that matter, I probably don't understand what you
mean by window-start "modified" and "unmodified", as you seem to
employ contradicting meanings: one when the marker moves but points to
the same text, the other when it doesn't move, but points to a
different text.

> >> Do you happen to know where is the C code that changes point
> >> (in response to scrolling) in the redisplay?
> > The part that begins under the force_start label in redisplay_window,
> > and is conditioned by the window's force_start flag.
> 
> Right, I see it (in xdisp.c) after the comment that says:
> 
>       /* If we need to move point for either of the above reasons,
> 	 now actually do it.  */
> 
> Playing with it, I see that this code is triggered very rarely.

As it should be.  It is mainly meant for scrolling commands.

> `scroll-up' doesn't go through this at all.

scroll-up calls window_scroll, which calls window_scroll_pixel_based,
which does set the force_start flag of the window, and thus does
trigger this portion of redisplay_window.

The force_start flag is _the_ way by which scrolling commands work:
they tell redisplay to heed to what they did.

> We also "set point in response to scrolling" in window_scroll_line_based
> and in window_scroll_pixel_based.

Which are called by scroll-up etc.

> There might be others.

Should be mostly (or only) scrolling commands.