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

[Stefan Monnier]

> But set-window-buffer is not a no-op when the buffer doesn't change.

I know, but it's pretty close.

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

That is allowed by the rule that says that such hooks may get run
unnecessarily at times.

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

I think that would be an improvement, yes.  Maybe not an important one, tho.

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

Agreed, it's the difference between modification and initialization.

So currently the hook is run not just when window-start is modified but
also when it's initialized.

> (Can you explain why calling it in split-window-internal might
> be useful?)

Not really, no.  I can vaguely understand it for the needs of linum.el
and lazy-lock.el, tho in practice the corresponding part of the buffer
should already have been displayed (and hence processed), so it's
probably not really useful there either.

For follow-mode and em-smart, I have no idea since I don't understand
how they work.

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

Of course, window-scroll-functions is never run automatically, it's only
ever run because we decide it should be run at that point and hence we
put the corresponding call in the code.  IOW it's not related to
anything by its nature and we could just never run it.  But that
wouldn't match the user(of window-scroll-functions)'s expectations,
would it?  Now would the problem be in our code or in the user's
expectation?  To figure that out, we have to read the docstring, and so
far I think the docstring is not precise enough, e.g. because
"scrolling" is not clear enough.

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

This sub-discussion was about my question:

   Do you happen to know where is the C code that changes point
   (in response to scrolling) in the redisplay?

and your helpful answer to it.

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

No, that was another sub-discussion.

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

I'll update window-scroll-functions's docstring to explain that it's run
whenever the window-start changes.


        Stefan