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

[Stefan Monnier]

> 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?

To know when you can be sure that it should be called and when it might
not be called.  Most of our hooks that react to changes (like
window-configuration-change-hook, menu-bar-update-hook, ...) have the
property that they may be called unnecessarily.  As long as it's not too
frequent, it shouldn't be a problem.  It's still useful to know when it
should be run and when it shouldn't, so that when we find a bug we can
tell whether it's in the hook function or in the caller of the hook.

> 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.

Maybe I misunderstood your examples, but by "marker moves" I mean that
something has done a set-marker: changes to marker-position due to
insertion/deletion of text doesn't count as moving the marker.

AFAICT all your examples indicate that window-scroll-functions is called
if and only if the marker is moved (plus a few spurious calls where we
didn't realize that the change was really a no-op).

>> Playing with it, I see that this code is triggered very rarely.
> As it should be.  It is mainly meant for scrolling commands.

By "rarely" I meant, "rarely even while scrolling".  The only "normal"
case where it seems to be triggered is if I scroll by moving the
scrollbar's thumb.

>> `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.

But by the time redisplay happens, window_scroll_pixel_based has already
moved point within the viewport, so the redisplay itself doesn't
change point (tho there might be corner cases where
window_scroll_pixel_based ends up putting point outside the viewport,
of course).

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

Yes, but the force_start flag rarely causes point to be moved, in
my experience.

>> There might be others.
> Should be mostly (or only) scrolling commands.

I'm not sure I understand.  If I want to catch all (i.e. exhaustively)
cases where scrolling moves point, do you think that catching the
redisplay_window case plus the window_scroll_pixel/line_based cases is
all that's needed?


        Stefan