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

[Josh]

On Thu, Oct 16, 2014 at 9:00 AM, Eli Zaretskii wrote:
>> There are so many ways that this can happen that it is not possible to
>> advise every function that might do it.  It is possible that
>> window-scroll-functions will give me everything I need, but I haven't
>> had time to try it yet.  We can resume this conversation at such a
>> time, unless there is someone else who already knows that
>> window-scroll-functions will not work.
>
> Sorry, I thought you only wanted this with a few specific commands.
> AFAIR, you never mentioned anything but the mouse-wheel scroll.

Sorry if I was not clear.  The request in the original bug-report was actually:

> I want to be notified when an update to the display will force the location of
> `point' to change in the current buffer.

On Thu, Oct 16, 2014 at 9:13 AM, Stefan Monnier wrote:
> So, w.r.t the original question in the bug-report, we still don't have
> an answer.  Do you happen to know where is the C code that changes point
> (in response to scrolling) in the redisplay?

I think you may be confusing the bug-report with my question on
StackOverflow. :)

On Thu, Oct 16, 2014 at 9:13 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> Does that include the case where window-start is changed
>>> so as to follow point or is it only the cases where window-start was
>>> changed explicitly by a scrolling command?
>> Both.
>
> So, could we say that this hook is supposed to be run if and only if
> the window-start marker is changed?
>
> 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).
>
> Of course, like most such hooks, it's OK if there are occasional false
> positives (i.e. the hook is run even unnecessarily).
>
> And as for "when" it is run: any time after the marker's modification
> and before updating the glyph matrices?  Is it run before or after
> computing the new mode-line (i.e. if the hook changes something that
> affects the mode-line, will that be reflected right away, or will it be
> delayed until the next redisplay)?
>
>>> - how could a window-scroll-function distinguish the 3 cases:
>>> "set-window-buffer", "used a scroll command", "moved point out of viewport".
>> I have no idea (but this is not exactly a question about the doc
>> string).
>
> So, w.r.t the original question in the bug-report, we still don't have
> an answer.  Do you happen to know where is the C code that changes point
> (in response to scrolling) in the redisplay?
>
>> Did the above clarifications help you?
>
> Yes, thanks.  I still don't really understand how/why follow-mode and
> em-smart.el work, tho.
>
>
>         Stefan