GNU bug report logs - #18739
24.3; Request for a hook to be provided when scrolling will move the cursor

Previous Next

Full log

Message #77 received at 18739 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: josh+gnu <at> nispio.net, 18739 <at> debbugs.gnu.org
Subject: Re: bug#18739: 24.3;
 Request for a hook to be provided when scrolling will move the cursor
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.

I think this "definition" of the behavior of window-scroll-functions is
more useful/precise.

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

>> And as for "when" it is run: any time after the marker's modification
>> and before updating the glyph matrices?
> Yes.
>> Is it run before or after computing the new mode-line
> Before.

Good, thanks.

>> 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.
`scroll-up' doesn't go through this at all.

We also "set point in response to scrolling" in window_scroll_line_based
and in window_scroll_pixel_based.  There might be others.

>> Yes, thanks.  I still don't really understand how/why follow-mode and
>> em-smart.el work, tho.
> Who does? ;-)

I think I'm beginning to understand why follow-mode's use of
window-scroll-functions works most of the time.  I think it relies on
the fact that it will first be called on window W1 even though the
window it cares about is W2, so it gets to (set-window-start W2
(point-max)) before redisplay gets a chance to change W2's window-start,
and afterwards, redisplay can't do that because of force_start.
And this "sticks" long enough to end a redisplay cycle.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.