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

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

[Josh]

It would be helpful to have a hook that would be called before any
scrolling command moves the cursor.  In other words, I want to be
notified when an update to the display will force the location of
`point' to change in the current buffer.

One motivation for such a hook is the ability to save the current
cursor location before scrolling so that it is possible to
automatically jump back to that position after scolling.

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

[Eli Zaretskii]

> Date: Wed, 15 Oct 2014 11:51:51 -0700
> From: Josh <josh+gnu@nispio.net>
> 
> It would be helpful to have a hook that would be called before any
> scrolling command moves the cursor.  In other words, I want to be
> notified when an update to the display will force the location of
> `point' to change in the current buffer.

What's wrong with window-scroll-functions?

> One motivation for such a hook is the ability to save the current
> cursor location before scrolling so that it is possible to
> automatically jump back to that position after scolling.

If you jump back, you will actually undo the scroll, so I'm not sure
what kind of situation are you talking about, or why do you use the
scrolling commands to begin with.  Please elaborate.

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

[Josh]

> If you jump back, you will actually undo the scroll, so I'm not sure
> what kind of situation are you talking about, or why do you use the
> scrolling commands to begin with.  Please elaborate.

I am writing code and I realize that I forgot the name of the variable
that I defined 30 lines ago, I use the mouse to do a quick scroll up,
read the name, and scroll back down where I came from.  The problem is
that now the cursor location has changed, and I have to spend time
trying to figure out which line I was typing on and moving my cursor
back to that position.  It would be nice if I could have the cursor
stay where I left it for the brief period that I peek elsewhere in the
buffer.

> What's wrong with window-scroll-functions?

I was looking for a hook, and did not see a relevant one. I was not
aware that window-scroll-functions existed, but it looks like it could
be a viable solution.  Thank you.

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

[Eli Zaretskii]

> Date: Wed, 15 Oct 2014 14:01:34 -0700
> From: Josh <josh+gnu@nispio.net>
> Cc: 18739@debbugs.gnu.org
> 
> > If you jump back, you will actually undo the scroll, so I'm not sure
> > what kind of situation are you talking about, or why do you use the
> > scrolling commands to begin with.  Please elaborate.
> 
> I am writing code and I realize that I forgot the name of the variable
> that I defined 30 lines ago, I use the mouse to do a quick scroll up,
> read the name, and scroll back down where I came from.  The problem is
> that now the cursor location has changed, and I have to spend time
> trying to figure out which line I was typing on and moving my cursor
> back to that position.  It would be nice if I could have the cursor
> stay where I left it for the brief period that I peek elsewhere in the
> buffer.

The usual technique in Emacs is to put the mark where you were before
scrolling.  Then "C-x C-x" will get you back.

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

[Josh Hunsaker]

> The usual technique in Emacs is to put the mark where you were before
> scrolling.  Then "C-x C-x" will get you back.

This requires the forethought to set the mark before scrolling.

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

[Ivan Shmakov]

>>>>> Josh Hunsaker <josh.huns@gmail.com> writes:

 >>> I am writing code and I realize that I forgot the name of the
 >>> variable that I defined 30 lines ago, I use the mouse to do a quick
 >>> scroll up, read the name, and scroll back down where I came from.

 >> The usual technique in Emacs is to put the mark where you were
 >> before scrolling.  Then "C-x C-x" will get you back.

 > This requires the forethought to set the mark before scrolling.

	Usually, I use incremental search (C-r) to look back at the
	code.  A side effect of that is that the mark gets set, so after
	I’ve looked what I was interested in up, – I can readily C-x C-x
	my way back.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

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

[Eli Zaretskii]

> From: Josh Hunsaker <josh.huns@gmail.com>
> Date: Wed, 15 Oct 2014 14:12:49 -0700
> Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org
> 
> > The usual technique in Emacs is to put the mark where you were before
> > scrolling.  Then "C-x C-x" will get you back.
> 
> This requires the forethought to set the mark before scrolling.

No, you can do it always.

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Josh Hunsaker <josh.huns@gmail.com>
>> Date: Wed, 15 Oct 2014 14:12:49 -0700
>> Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org
>> 
>> > The usual technique in Emacs is to put the mark where you were before
>> > scrolling.  Then "C-x C-x" will get you back.
>> 
>> This requires the forethought to set the mark before scrolling.
>
> No, you can do it always.

Then you lose the previous mark.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Josh Hunsaker <josh.huns@gmail.com>,  josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 09:15:08 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Josh Hunsaker <josh.huns@gmail.com>
> >> Date: Wed, 15 Oct 2014 14:12:49 -0700
> >> Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org
> >> 
> >> > The usual technique in Emacs is to put the mark where you were before
> >> > scrolling.  Then "C-x C-x" will get you back.
> >> 
> >> This requires the forethought to set the mark before scrolling.
> >
> > No, you can do it always.
> 
> Then you lose the previous mark.

Not if it's pushed.

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: Josh Hunsaker <josh.huns@gmail.com>,  josh+gnu@nispio.net,  18739@debbugs.gnu.org
>> Date: Thu, 16 Oct 2014 09:15:08 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Josh Hunsaker <josh.huns@gmail.com>
>> >> Date: Wed, 15 Oct 2014 14:12:49 -0700
>> >> Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org
>> >> 
>> >> > The usual technique in Emacs is to put the mark where you were before
>> >> > scrolling.  Then "C-x C-x" will get you back.
>> >> 
>> >> This requires the forethought to set the mark before scrolling.
>> >
>> > No, you can do it always.
>> 
>> Then you lose the previous mark.
>
> Not if it's pushed.

C-x C-x only uses the current mark.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org,  josh.huns@gmail.com
> Date: Thu, 16 Oct 2014 09:38:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Cc: Josh Hunsaker <josh.huns@gmail.com>,  josh+gnu@nispio.net,  18739@debbugs.gnu.org
> >> Date: Thu, 16 Oct 2014 09:15:08 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> From: Josh Hunsaker <josh.huns@gmail.com>
> >> >> Date: Wed, 15 Oct 2014 14:12:49 -0700
> >> >> Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org
> >> >> 
> >> >> > The usual technique in Emacs is to put the mark where you were before
> >> >> > scrolling.  Then "C-x C-x" will get you back.
> >> >> 
> >> >> This requires the forethought to set the mark before scrolling.
> >> >
> >> > No, you can do it always.
> >> 
> >> Then you lose the previous mark.
> >
> > Not if it's pushed.
> 
> C-x C-x only uses the current mark.

Which is what the OP wants.  Later, he can restore the other marks
from the ring, if that is needed.

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

[Stefan Monnier]

>> It would be helpful to have a hook that would be called before any
>> scrolling command moves the cursor.  In other words, I want to be
>> notified when an update to the display will force the location of
>> `point' to change in the current buffer.
> What's wrong with window-scroll-functions?

But these are also called when point is not affected, right?

>> One motivation for such a hook is the ability to save the current
>> cursor location before scrolling so that it is possible to
>> automatically jump back to that position after scolling.
> If you jump back, you will actually undo the scroll, so I'm not sure
> what kind of situation are you talking about, or why do you use the
> scrolling commands to begin with.  Please elaborate.

He's thinking of scrolling back a while later.

Think about a case such as Martin's scroll-replace.el (just added to GNU
ELPA).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Wed, 15 Oct 2014 18:48:16 -0400
> 
> >> It would be helpful to have a hook that would be called before any
> >> scrolling command moves the cursor.  In other words, I want to be
> >> notified when an update to the display will force the location of
> >> `point' to change in the current buffer.
> > What's wrong with window-scroll-functions?
> 
> But these are also called when point is not affected, right?

Yes.  But it's easy to detect that situation, I think.

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

[Stefan Monnier]

>> >> It would be helpful to have a hook that would be called before any
>> >> scrolling command moves the cursor.  In other words, I want to be
>> >> notified when an update to the display will force the location of
>> >> `point' to change in the current buffer.
>> > What's wrong with window-scroll-functions?
>> But these are also called when point is not affected, right?
> Yes.  But it's easy to detect that situation, I think.

Is it?

I think the main reason why I ask is because I truly have no idea when
window-scroll-functions is called.  You seem to be somewhat familiar
with it, so could you try and clarify it in the docstring?

Currently I see "List of functions to call before redisplaying a window
with scrolling" and "Note that these functions are also called by
`set-window-buffer'".

Here are some of the questions this brings up for me:
- is it called during set-window-buffer itself, or is it called in the
  first redisplay after set-window-buffer?
- what means "redisplaying a window with scrolling" exactly?  Does it
  mean "redisplay with a different window-start then during the last
  redisplay"?  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?
- how could a window-scroll-function distinguish the 3 cases:
  "set-window-buffer", "used a scroll command", "moved point out of viewport".

I tried already a few times to understand window-scroll-functions, but
so far it has eluded me.  FWIW, I found 3 kinds of uses:
- A crutch from when jit-lock didn't exist (in linum and lazy-lock).
- A way to try and keep a window fully empty showing only point-max by
  calling set-window-start with the same window-start (in follow-mode).
  Not clear exactly why this should work, and arguably goes against the
  warning in window-scroll-functions's docstring.
- Do fancy auto-scrolling in eshell/em-smart (which does exactly what
  window-scroll-functions's docstring warns not to do, AFAICT), calling
  redisplay internally.


        Stefan

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

[Josh]

>>> The usual technique in Emacs is to put the mark where you were before
>>> scrolling.  Then "C-x C-x" will get you back.

>> This requires the forethought to set the mark before scrolling.

> No, you can do it always.

I don't understand. If I don't set the mark, how will "C-x C-x" know
where to jump back to?  I have experimented to see if I can replicate
the behavior that you are describing, but I cannot:

 (Copy many paragraphs of lorem ipsum text to the OS clipboard)
 $ emacs -Q
 C-y
 C-x h
 M-q
 C-u 12 C-n
 M-f
 M-f
 SPC
 H
 E
 R
 E
 <wheel-down> (until the cursor is forced to move)
 <wheel-up> (until the word "HERE" is visible again)
 C-x C-x

This does not jump the cursor back to the word "HERE" which is the
behavior that I am looking for.  I have also tried setting
transient-mark-mode to nil, but it does not do what I want either.

So again, I assert my claim that using "C-x C-x" requires that I have
the forethought to set the mark before I scroll.  Please tell me if I
am misunderstanding.

On Thu, Oct 16, 2014 at 7:44 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> >> It would be helpful to have a hook that would be called before any
>>> >> scrolling command moves the cursor.  In other words, I want to be
>>> >> notified when an update to the display will force the location of
>>> >> `point' to change in the current buffer.
>>> > What's wrong with window-scroll-functions?
>>> But these are also called when point is not affected, right?
>> Yes.  But it's easy to detect that situation, I think.
>
> Is it?
>
> I think the main reason why I ask is because I truly have no idea when
> window-scroll-functions is called.  You seem to be somewhat familiar
> with it, so could you try and clarify it in the docstring?
>
> Currently I see "List of functions to call before redisplaying a window
> with scrolling" and "Note that these functions are also called by
> `set-window-buffer'".
>
> Here are some of the questions this brings up for me:
> - is it called during set-window-buffer itself, or is it called in the
>   first redisplay after set-window-buffer?
> - what means "redisplaying a window with scrolling" exactly?  Does it
>   mean "redisplay with a different window-start then during the last
>   redisplay"?  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?
> - how could a window-scroll-function distinguish the 3 cases:
>   "set-window-buffer", "used a scroll command", "moved point out of viewport".
>
> I tried already a few times to understand window-scroll-functions, but
> so far it has eluded me.  FWIW, I found 3 kinds of uses:
> - A crutch from when jit-lock didn't exist (in linum and lazy-lock).
> - A way to try and keep a window fully empty showing only point-max by
>   calling set-window-start with the same window-start (in follow-mode).
>   Not clear exactly why this should work, and arguably goes against the
>   warning in window-scroll-functions's docstring.
> - Do fancy auto-scrolling in eshell/em-smart (which does exactly what
>   window-scroll-functions's docstring warns not to do, AFAICT), calling
>   redisplay internally.
>
>
>         Stefan

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

[Eli Zaretskii]

> Date: Thu, 16 Oct 2014 07:53:22 -0600
> From: Josh <josh+gnu@nispio.net>
> Cc: 18739@debbugs.gnu.org
> 
> >>> The usual technique in Emacs is to put the mark where you were before
> >>> scrolling.  Then "C-x C-x" will get you back.
> 
> >> This requires the forethought to set the mark before scrolling.
> 
> > No, you can do it always.
> 
> I don't understand. If I don't set the mark, how will "C-x C-x" know
> where to jump back to?

I meant set the mark as part of the command that is run by the wheel
scroll, or manually just before you scroll.

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

[Josh]

On Thu, Oct 16, 2014 at 8:25 AM, Eli Zaretskii wrote:
>> >>> The usual technique in Emacs is to put the mark where you were before
>> >>> scrolling.  Then "C-x C-x" will get you back.
>>
>> >> This requires the forethought to set the mark before scrolling.
>>
>> > No, you can do it always.
>>
>> I don't understand. If I don't set the mark, how will "C-x C-x" know
>> where to jump back to?
>
> I meant set the mark as part of the command that is run by the wheel
> scroll, or manually just before you scroll.

If I configure the scroll wheel to set the mark every time I use it,
then imagine how many times I might have to pop the mark to get back
where I started if I scrolled down multiple screens.  This is not
practical.  And telling me to set the mark manually before I scroll is
avoiding the issue.

I want to know where the cursor was *the last time I used it*, and be
able to easily jump back to that spot.

On Thu, Oct 16, 2014 at 8:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 16 Oct 2014 07:53:22 -0600
>> From: Josh <josh+gnu@nispio.net>
>> Cc: 18739@debbugs.gnu.org
>>
>> >>> The usual technique in Emacs is to put the mark where you were before
>> >>> scrolling.  Then "C-x C-x" will get you back.
>>
>> >> This requires the forethought to set the mark before scrolling.
>>
>> > No, you can do it always.
>>
>> I don't understand. If I don't set the mark, how will "C-x C-x" know
>> where to jump back to?
>
> I meant set the mark as part of the command that is run by the wheel
> scroll, or manually just before you scroll.

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

[Eli Zaretskii]

> Date: Thu, 16 Oct 2014 08:35:03 -0600
> From: Josh <josh+gnu@nispio.net>
> Cc: 18739@debbugs.gnu.org
> 
> > I meant set the mark as part of the command that is run by the wheel
> > scroll, or manually just before you scroll.
> 
> If I configure the scroll wheel to set the mark every time I use it,
> then imagine how many times I might have to pop the mark to get back
> where I started if I scrolled down multiple screens.

If repeated use of mouse-wheel scroll is the issue, you can avoid
multiple settings or the mark by looking at last-command and
this-command.  There are already Emacs commands that behave
differently depending on whether they are repeated or not; one
prominent example is C-n and C-p.  So there are examples you could
study to see how this technique is applied.

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

[Josh]

On Thu, Oct 16, 2014 at 8:46 AM, Eli Zaretskii wrote:
>> > I meant set the mark as part of the command that is run by the wheel
>> > scroll, or manually just before you scroll.
>>
>> If I configure the scroll wheel to set the mark every time I use it,
>> then imagine how many times I might have to pop the mark to get back
>> where I started if I scrolled down multiple screens.
>
> If repeated use of mouse-wheel scroll is the issue, you can avoid
> multiple settings or the mark by looking at last-command and
> this-command.  There are already Emacs commands that behave
> differently depending on whether they are repeated or not; one
> prominent example is C-n and C-p.  So there are examples you could
> study to see how this technique is applied.

I feel like this conversation is missing the point (no pun intended).
Let me restate the problem: I am looking for a way to maintain cursor
position within a buffer, even when other events cause that position
to be moved beyond the edges of the window.

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.

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

[Eli Zaretskii]

> Date: Thu, 16 Oct 2014 08:58:25 -0600
> From: Josh <josh+gnu@nispio.net>
> Cc: 18739@debbugs.gnu.org
> 
> Let me restate the problem: I am looking for a way to maintain cursor
> position within a buffer, even when other events cause that position
> to be moved beyond the edges of the window.
> 
> 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.

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

[Lars Ingebrigtsen]

Josh <josh+gnu@nispio.net> writes:

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

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was seven years ago, but no follow-up happened, as far as I can
tell.

window-scroll-functions is the variable to use when doing stuff if the
window start changes (which will often move point).  A more general
hook, to be run whenever point changes, would be too heavy, because
point movement functions are called all the time and have to be
efficient.

So I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 09:44:34 -0400
> 
> >> >> It would be helpful to have a hook that would be called before any
> >> >> scrolling command moves the cursor.  In other words, I want to be
> >> >> notified when an update to the display will force the location of
> >> >> `point' to change in the current buffer.
> >> > What's wrong with window-scroll-functions?
> >> But these are also called when point is not affected, right?
> > Yes.  But it's easy to detect that situation, I think.
> 
> Is it?

I think.

> I think the main reason why I ask is because I truly have no idea when
> window-scroll-functions is called.  You seem to be somewhat familiar
> with it, so could you try and clarify it in the docstring?

When it's clear what to clarify, I will ;-)

> Currently I see "List of functions to call before redisplaying a window
> with scrolling" and "Note that these functions are also called by
> `set-window-buffer'".

That's correct.

> Here are some of the questions this brings up for me:
> - is it called during set-window-buffer itself, or is it called in the
>   first redisplay after set-window-buffer?

The former, see window.c:set_window_buffer.

> - what means "redisplaying a window with scrolling" exactly?  Does it
>   mean "redisplay with a different window-start then during the last
>   redisplay"?

Yes, that's one of the causes.  For example, if point moved outside
the window.

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

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

> I tried already a few times to understand window-scroll-functions, but
> so far it has eluded me.  FWIW, I found 3 kinds of uses:
> - A crutch from when jit-lock didn't exist (in linum and lazy-lock).
> - A way to try and keep a window fully empty showing only point-max by
>   calling set-window-start with the same window-start (in follow-mode).
>   Not clear exactly why this should work, and arguably goes against the
>   warning in window-scroll-functions's docstring.
> - Do fancy auto-scrolling in eshell/em-smart (which does exactly what
>   window-scroll-functions's docstring warns not to do, AFAICT), calling
>   redisplay internally.

Did the above clarifications help you?

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

[Stefan Monnier]

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

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 11:13:59 -0400
> 
> >> 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?

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.

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

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.

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

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

I actually don't really understand what was the question anymore, see
the other thread of discussion.

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

> > Did the above clarifications help you?
> 
> Yes, thanks.  I still don't really understand how/why follow-mode and
> em-smart.el work, tho.

Who does? ;-)

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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> 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.

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?

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

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.

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

As it should be.  It is mainly meant for scrolling commands.

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

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

> We also "set point in response to scrolling" in window_scroll_line_based
> and in window_scroll_pixel_based.

Which are called by scroll-up etc.

> There might be others.

Should be mostly (or only) scrolling commands.

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: josh+gnu@nispio.net,  18739@debbugs.gnu.org
> Date: Thu, 16 Oct 2014 17:24:43 -0400
> 
> > 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.

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.

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

If you insert text at the beginning of a line whose first character
was the window-start, then according to the above definition the
marker _will_ move, because Emacs will likely reset it to the new
beginning of the line, or maybe even to one of the following lines
(the latter if point moves out of the view as result of the
insertion).

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

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.  But actually, there's no
causality here; both movement of window-start and a call to
window-scroll-functions are side effects of Emacs scrolling the
window in some sense.

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

That's not my reading of the code.  (Not sure why it matters, though.)

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

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.  And that's okay, because
this is how scrolling commands cause window-scroll-functions to be
called.  You will even see comments to that effect in window.c.

Again, I'm not sure why it is important whether the hook is called
frequently or not in some situation where it has to be called.

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

Maybe so, but (a) I again don't understand why the frequency matters,
and (b) my reading of the code is that the hook will be called even if
point doesn't need to be repositioned.  The hook should be called to
reflect the fact that we scrolled, even if point didn't move.

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

Yes, I think so.

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

[Stefan Monnier]

> 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), so 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.

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

>> >> 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.
> That's not my reading of the code.  (Not sure why it matters, though.)

I don't understand the code nearly enough, so instead I asked fprintf,
and she sounded pretty definitive ;-)

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

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

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


        Stefan

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

[Eli Zaretskii]

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

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