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: Fri, 17 Oct 2014 09:04:05 -0400
> 
> > I'm not sure I get your point.  But if you mean to say something that
> > is already said in the doc string, i.e.
> 
> >   List of functions to call before redisplaying a window with scrolling.
> >   [...] Note that these functions are also called by `set-window-buffer'.
> 
> > then I'm okay with that.
> 
> No, I'm trying to find a definition that justifies *why*
> set-window-buffer runs the hook.  `set-window-buffer' changes the
> window-start marker to point into another buffer (except when
> set-window-buffer is basically a no-op)

But set-window-buffer is not a no-op when the buffer doesn't change.
Moreover, saying that window-scroll-functions will be called when the
window-start marker changes will miss those calls when it didn't, and
yet set-window-buffer still called the hook.

Maybe we should refrain from calling window-scroll-functions when the
buffer doesn't change.

> saying "the hook is run whenever the window-start marker is
> modified" does explain why set-window-buffer should run the hook.
> It also explains why split-window should run the hook.

If you mean the fact that a new marker is created for the new window,
then yes; but that's a technicality that will not be obvious to
semi-naive readers of the documentation, and will probably be
unexpected by at least some of them.

So either we say that explicitly in the doc string, or we should
change split-window-internal not to call the hook.  (Can you explain
why calling it in split-window-internal might be useful?)

> > I don't like this "conclusion", because it can be interpreted as
> > meaning that moving the window-start marker _causes_
> > window-scroll-functions to be called.
> 
> No, it just means that moving the marker creates the need for Emacs to run
> the hook.

That's not what "iff" usually means.  Moreover, we could modify the
code to do one, but not the other in some cases.  They are unrelated.

> > If the window's force_start flag is set when redisplay is entered,
> > then my reading of the code is that window-scroll-functions will be
> > called even if point doesn't have to move.
> 
> I'm not talking about calling window-scroll-functions, I'm talking about
> moving point (a bit further down in the redisplay_window function).

Well, of course point will be moved only if necessary.  But this
discussion is about the hook and when it is called, not about
adjusting point.

> > Maybe so, but (a) I again don't understand why the frequency matters,
> 
> It doesn't.  I was just pointing out that this is not the main place
> where scrolling moves point.

The issue we were discussing was the conditions under which the hook
is called, wasn't it?

> >> 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?
> > Yes, I think so.
> 
> OK, thanks,

So what, if anything, needs to be clarified in the docs?