bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Hello,

I discovered that when scrolling with the mouse wheel while
`pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
not run.  Should they be?


TIA,

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 06 Feb 2023 02:49:54 +0100
> 
> I discovered that when scrolling with the mouse wheel while
> `pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
> not run.  Should they be?

Are you saying that window-scroll-functions are _never_ run, no matter
how far and for how long you are scrolling?  Or are they sometimes run
and sometimes not, like only if you scroll far enough?

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > I discovered that when scrolling with the mouse wheel while
> > `pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
> > not run.  Should they be?
>
> Are you saying that window-scroll-functions are _never_ run, no matter
> how far and for how long you are scrolling?  Or are they sometimes run
> and sometimes not, like only if you scroll far enough?

No, never, as far as I can tell.

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Mon, 06 Feb 2023 22:30:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > I discovered that when scrolling with the mouse wheel while
> > > `pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
> > > not run.  Should they be?
> >
> > Are you saying that window-scroll-functions are _never_ run, no matter
> > how far and for how long you are scrolling?  Or are they sometimes run
> > and sometimes not, like only if you scroll far enough?
> 
> No, never, as far as I can tell.

So I guess we should add calls to window-scroll-functions inside
pixel-scroll.el functions which actually scroll.  Patches welcome.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So I guess we should add calls to window-scroll-functions inside
> pixel-scroll.el functions which actually scroll.  Patches welcome.

pixel-scroll-mode (without "precision") already behaves correctly,
AFAICT.

pixel-scroll-precision-mode has basically one command in its minor mode
map that does not call the w-s-functions: `pixel-scroll-precision'.

So the naïve approach would be: call `window-scroll-functions' at the
end of that command.  Is this the right direction?  Else I guess I'm not
qualified here.  Haven't checked that momentum stuff (for scrolling) yet.


Thanks,

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Mon, 13 Feb 2023 03:20:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So I guess we should add calls to window-scroll-functions inside
> > pixel-scroll.el functions which actually scroll.  Patches welcome.
> 
> pixel-scroll-mode (without "precision") already behaves correctly,
> AFAICT.
> 
> pixel-scroll-precision-mode has basically one command in its minor mode
> map that does not call the w-s-functions: `pixel-scroll-precision'.
> 
> So the naïve approach would be: call `window-scroll-functions' at the
> end of that command.  Is this the right direction?  Else I guess I'm not
> qualified here.  Haven't checked that momentum stuff (for scrolling) yet.

Each command would be too often, I think, since this could be every
pixel.  So I thought about some factor, perhaps configurable via a
variable, that would cause the call to be done every N pixels of
scroll.

WDYT?

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Each command would be too often, I think, since this could be every
> pixel.  So I thought about some factor, perhaps configurable via a
> variable, that would cause the call to be done every N pixels of
> scroll.
>
> WDYT?

Don't all other scroll commands scroll after every single command
invocation?  Why is this one different?  The scroll amounts are finer
grained, but the amounts are not smaller.  AFAIU the w-scroll-functions
would not be called for each single scrolled pixel.


Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Mon, 13 Feb 2023 04:44:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Each command would be too often, I think, since this could be every
> > pixel.  So I thought about some factor, perhaps configurable via a
> > variable, that would cause the call to be done every N pixels of
> > scroll.
> >
> > WDYT?
> 
> Don't all other scroll commands scroll after every single command
> invocation?  Why is this one different?

Because you might make scrolling much slower if you call the scroll
functions every pixel.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> > Don't all other scroll commands scroll after every single command
> > invocation?  Why is this one different?
>
> Because you might make scrolling much slower if you call the scroll
> functions every pixel.

Sorry that I repeat myself, but I don't understand why that would
happen.  This is what I tried:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 61307.diff --]
[-- Type: text/x-diff, Size: 1017 bytes --]

*** /tmp/ediffnuE8b2	2023-02-14 02:24:24.300444006 +0100
--- /home/micha/software/emacs/lisp/pixel-scroll.el	2023-02-14 02:20:40.472154353 +0100
***************
*** 725,731 ****
                      (beginning-of-buffer
                       (message (error-message-string '(beginning-of-buffer))))
                      (end-of-buffer
!                      (message (error-message-string '(end-of-buffer))))))))))
        (mwheel-scroll event nil))))

  (defun pixel-scroll-kinetic-state (&optional window)
--- 725,733 ----
                      (beginning-of-buffer
                       (message (error-message-string '(beginning-of-buffer))))
                      (end-of-buffer
!                      (message (error-message-string '(end-of-buffer))))))
!                 (run-hook-with-args 'window-scroll-functions
!                                     (selected-window) (window-start))))))
        (mwheel-scroll event nil))))

  (defun pixel-scroll-kinetic-state (&optional window)

[-- Attachment #3: Type: text/plain, Size: 534 bytes --]


I don't see the hook called for each pixel.  What do you mean?


A second thing I wonder about: the docstring of
`window-scroll-functions' says:

| These functions are called whenever the `window-start' marker is modified,
| either to point into another buffer (e.g. via `set-window-buffer') or another
| place in the same buffer.

Is this correct and complete?  Is the window-start marker modified in
our scenario?  If it is, why do we have to call the hook explicitly?  If
it is not, should we update that marker?


TIA,

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 02:30:10 +0100
> 
> > Because you might make scrolling much slower if you call the scroll
> > functions every pixel.
> 
> Sorry that I repeat myself, but I don't understand why that would
> happen.  This is what I tried:
> 
> *** /tmp/ediffnuE8b2	2023-02-14 02:24:24.300444006 +0100
> --- /home/micha/software/emacs/lisp/pixel-scroll.el	2023-02-14 02:20:40.472154353 +0100
> ***************
> *** 725,731 ****
>                       (beginning-of-buffer
>                        (message (error-message-string '(beginning-of-buffer))))
>                       (end-of-buffer
> !                      (message (error-message-string '(end-of-buffer))))))))))
>         (mwheel-scroll event nil))))
> 
>   (defun pixel-scroll-kinetic-state (&optional window)
> --- 725,733 ----
>                       (beginning-of-buffer
>                        (message (error-message-string '(beginning-of-buffer))))
>                       (end-of-buffer
> !                      (message (error-message-string '(end-of-buffer))))))
> !                 (run-hook-with-args 'window-scroll-functions
> !                                     (selected-window) (window-start))))))
>         (mwheel-scroll event nil))))
> 
>   (defun pixel-scroll-kinetic-state (&optional window)
> 
> I don't see the hook called for each pixel.  What do you mean?

Each time you do the smallest possible scroll, by how many pixels, or
by what fraction of the screen-line's height does Emacs scroll the
window?  IOW, by how many pixels is the display scrolled for each call
to window-scroll-functions?

Precision pixel-scrolling supports many different devices (mice and
touch-pads), which can scroll at very different resolutions.  The
possibility that window-scroll-functions be called too frequently
depends on what exactly do your device and your Emacs build support in
this scenario, and I don't yet have a clear idea about that, since you
didn't tell.

> A second thing I wonder about: the docstring of
> `window-scroll-functions' says:
> 
> | These functions are called whenever the `window-start' marker is modified,
> | either to point into another buffer (e.g. via `set-window-buffer') or another
> | place in the same buffer.
> 
> Is this correct and complete?

More or less.  (I don't like how it explains this stuff by using
internal implementation detail, but I cannot think of a better
explanation that is still accurate enough.)

> Is the window-start marker modified in our scenario?

Not in the way that the "usual" scrolling commands do.  This mode uses
non-nil 3rd argument to set-window-start.  So the display engine
doesn't know that the window is scrolled.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > I don't see the hook called for each pixel.  What do you mean?
>
> Each time you do the smallest possible scroll, by how many pixels, or
> by what fraction of the screen-line's height does Emacs scroll the
> window?  IOW, by how many pixels is the display scrolled for each call
> to window-scroll-functions?
>
> Precision pixel-scrolling supports many different devices (mice and
> touch-pads), which can scroll at very different resolutions.  The
> possibility that window-scroll-functions be called too frequently
> depends on what exactly do your device and your Emacs build support in
> this scenario, and I don't yet have a clear idea about that, since you
> didn't tell.

I feel a bit lost.  What should I tell?  I have no idea what I could
know about this that you don't already know.

But I understand that what I see when scrolling with a normal wheel
mouse is only one case we need to handle.  AFAIU, scrolling by
dragging the vertical scroll bar is not handled by precision scrolling.

So we speak about touch events (although
`pixel-scroll-precision-mode-map' only binds <touch-end>, but that event
may also be generated very often) and mice with a more or less
continuous scroll wheel (or ball) and such things.

I don't have access to such a device and really feel uncomfortable to
suggest a patch for these cases I must admit.

Or would you suggest to call the window-scroll functions just after a
certain time limit?  A pixel-delta limit would probably not be
sufficient, since we want to call the functions also for small scroll
amounts if they are not directly followed by another scroll (I guess).

So do we just want to use a timer for this?  Or use a combination of
those approaches (scrolling farther than a certain amount fires the
scroll functions immediately, but also small amounts call them if the
user doesn't scroll after delta more milliseconds)?


Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Wed, 15 Feb 2023 05:06:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > I don't see the hook called for each pixel.  What do you mean?
> >
> > Each time you do the smallest possible scroll, by how many pixels, or
> > by what fraction of the screen-line's height does Emacs scroll the
> > window?  IOW, by how many pixels is the display scrolled for each call
> > to window-scroll-functions?
> >
> > Precision pixel-scrolling supports many different devices (mice and
> > touch-pads), which can scroll at very different resolutions.  The
> > possibility that window-scroll-functions be called too frequently
> > depends on what exactly do your device and your Emacs build support in
> > this scenario, and I don't yet have a clear idea about that, since you
> > didn't tell.
> 
> I feel a bit lost.  What should I tell?  I have no idea what I could
> know about this that you don't already know.

I hoped you will answer the specific questions I asked, quoted above.
But since you don't have a device to actually observe
pixel-scroll-precision-mode on your system, something I didn't know
until now, I guess you cannot answer them?  (I also don't have access
to a suitable system, otherwise I wouldn't have bothered you with the
questions.)

> But I understand that what I see when scrolling with a normal wheel
> mouse is only one case we need to handle.

Right.  Though on such a system, we should probably call
window-scroll-functions every scroll.

> AFAIU, scrolling by
> dragging the vertical scroll bar is not handled by precision scrolling.

Correct.

> So we speak about touch events (although
> `pixel-scroll-precision-mode-map' only binds <touch-end>, but that event
> may also be generated very often) and mice with a more or less
> continuous scroll wheel (or ball) and such things.

Yes, capable mice (which also require a capable system to support
them), and touch pads.

> Or would you suggest to call the window-scroll functions just after a
> certain time limit?

I don't think a timer would be appropriate here.

> A pixel-delta limit would probably not be
> sufficient, since we want to call the functions also for small scroll
> amounts if they are not directly followed by another scroll (I guess).

Not necessarily.  To see a similar situation, disable
image-auto-resize mode, visit a large image, and scroll with C-n or
C-p: you won't see window-scroll-functions called at all.  That's
basically what pixel-scroll-precision-mode works: it uses the window's
vscroll, like we do with tall images.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:


> > > Each time you do the smallest possible scroll, by how many pixels, or
> > > by what fraction of the screen-line's height does Emacs scroll the
> > > window?  IOW, by how many pixels is the display scrolled for each call
> > > to window-scroll-functions?

> I hoped you will answer the specific questions I asked, quoted above.
> But since you don't have a device to actually observe
> pixel-scroll-precision-mode on your system, something I didn't know
> until now, I guess you cannot answer them?  (I also don't have access
> to a suitable system, otherwise I wouldn't have bothered you with the
> questions.)

[ I'm sorry, I totally misunderstood your question as rhetorical, for me
to think and understand ]

I'm using a normal wheel mouse.  I have nevertheless enabled
`pixel-scroll-precision-mode' for two reasons: I want to have the
animated "smooth scrolling" like known from browsers, which looks nicer
and seems to be better for the eyes/ the brain.  And I want to get a
better scrolling experience for images (pdf, and such things).

And the answer to your question is: I get a scroll amount of
approximately 7 lines per <wheel-up> or <wheel-down> event.  I
configured pixel-scroll-precision-interpolation-factor to 1.5, the
original value of 2.0 was a bit too large in my experience.

> > But I understand that what I see when scrolling with a normal wheel
> > mouse is only one case we need to handle.

> Right.  Though on such a system, we should probably call
> window-scroll-functions every scroll.

Is receiving <wheel-up> and <wheel-down> events a sufficient hint that
the user is scrolling using a "normal" wheel mouse?


Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 61307@debbugs.gnu.org
> Date: Thu, 16 Feb 2023 05:57:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > But I understand that what I see when scrolling with a normal wheel
> > > mouse is only one case we need to handle.
> 
> > Right.  Though on such a system, we should probably call
> > window-scroll-functions every scroll.
> 
> Is receiving <wheel-up> and <wheel-down> events a sufficient hint that
> the user is scrolling using a "normal" wheel mouse?

I'm not sure, but Po Lu will know.

In any case, AFAIR some mice produce mouse-4 and mouse-5 events
instead, so relying on the events' symbols might not be the best
idea.  We are supposed to know whether the device supports pixel
precision, so maybe basing the decision on that is better?

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Heerdegen <michael_heerdegen@web.de>
>> Cc: 61307@debbugs.gnu.org
>> Date: Thu, 16 Feb 2023 05:57:18 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > > But I understand that what I see when scrolling with a normal wheel
>> > > mouse is only one case we need to handle.
>> 
>> > Right.  Though on such a system, we should probably call
>> > window-scroll-functions every scroll.
>> 
>> Is receiving <wheel-up> and <wheel-down> events a sufficient hint that
>> the user is scrolling using a "normal" wheel mouse?
>
> I'm not sure, but Po Lu will know.
>
> In any case, AFAIR some mice produce mouse-4 and mouse-5 events
> instead, so relying on the events' symbols might not be the best
> idea.  We are supposed to know whether the device supports pixel
> precision, so maybe basing the decision on that is better?

Try:

  (device-class last-event-frame last-event-device)

but I will eventually get around to replacing this with some virtual
modifier key in Emacs 30.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> In any case, AFAIR some mice produce mouse-4 and mouse-5 events
> instead, so relying on the events' symbols might not be the best
> idea.  We are supposed to know whether the device supports pixel
> precision, so maybe basing the decision on that is better?

No idea.  Hoping Po Lu can help.

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure, but Po Lu will know.
>
> In any case, AFAIR some mice produce mouse-4 and mouse-5 events
> instead, so relying on the events' symbols might not be the best
> idea.  We are supposed to know whether the device supports pixel
> precision, so maybe basing the decision on that is better?

So, would this already be good enough as a start?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ps.diff --]
[-- Type: text/x-diff, Size: 846 bytes --]

diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index 487144144f5..1d2d3ff10fe 100644
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -714,7 +714,10 @@ pixel-scroll-precision
                       (let ((kin-state (pixel-scroll-kinetic-state)))
                         (aset kin-state 0 (make-ring 30))
                         (aset kin-state 1 nil))
-                      (pixel-scroll-precision-interpolate delta current-window))
+                      (pixel-scroll-precision-interpolate delta current-window)
+                      (run-hook-with-args 'window-scroll-functions
+                                          current-window
+                                          (window-start current-window)))
                   (condition-case nil
                       (progn
                         (if (< delta 0)

[-- Attachment #3: Type: text/plain, Size: 132 bytes --]


AFAIU, in that branch of the code we know that we are presumably dealing
with a mouse or we scrolled by a larger amount.

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'm not sure, but Po Lu will know.
>>
>> In any case, AFAIR some mice produce mouse-4 and mouse-5 events
>> instead, so relying on the events' symbols might not be the best
>> idea.  We are supposed to know whether the device supports pixel
>> precision, so maybe basing the decision on that is better?
>
> So, would this already be good enough as a start?
>
> diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
> index 487144144f5..1d2d3ff10fe 100644
> --- a/lisp/pixel-scroll.el
> +++ b/lisp/pixel-scroll.el
> @@ -714,7 +714,10 @@ pixel-scroll-precision
>                        (let ((kin-state (pixel-scroll-kinetic-state)))
>                          (aset kin-state 0 (make-ring 30))
>                          (aset kin-state 1 nil))
> -                      (pixel-scroll-precision-interpolate delta current-window))
> +                      (pixel-scroll-precision-interpolate delta current-window)
> +                      (run-hook-with-args 'window-scroll-functions
> +                                          current-window
> +                                          (window-start current-window)))
>                    (condition-case nil
>                        (progn
>                          (if (< delta 0)
>
>
> AFAIU, in that branch of the code we know that we are presumably dealing
> with a mouse or we scrolled by a larger amount.
>
> Michael.

What if you are scrolling with a touch pad or core pointer that never
triggers the ``large scroll'' options?

Either way, please make sure it stays fast (or at least put it behind an
option which is off by default.)

If window-scroll-functions are not called, then it stays tolerable for
many people.  But users will become extremely annoyed if precision pixel
scrolling becomes too slow.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> What if you are scrolling with a touch pad or core pointer that never
> triggers the ``large scroll'' options?

That is also my question!

> Either way, please make sure it stays fast (or at least put it behind an
> option which is off by default.)

How can I be sure it stays fast?  It's obviously the right thing for my
setup, but I have _zero_ experience with other setups (devices).  If you
have, help would be very appreciated.

Michael.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> That is also my question!

I suggest adding a new counter to the kinetic state which counts the
number of pixels scrolled, taking into account the direction of the
scroll.  Then, once (abs counter) exceeds the line height, run
window-scroll-functions.

Alternatively, do that every time set-window-start is called.

>> Either way, please make sure it stays fast (or at least put it behind an
>> option which is off by default.)
>
> How can I be sure it stays fast?  It's obviously the right thing for my
> setup, but I have _zero_ experience with other setups (devices).  If you
> have, help would be very appreciated.

I'd recommend asking people to try it, especially with editing modes
that have lots of gizmos (``lsp-ui'' seems to be one of those, whatever
it is.)

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hello,
>
> I discovered that when scrolling with the mouse wheel while
> `pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
> not run.  Should they be?
>
>
> TIA,
>
> Michael.

IIRC this is due to how pixel-scroll-precision-mode calls
set-window-start with NOFORCE set to t.

Patches welcome, but please make sure they do not slow precision
scrolling down.

bug#61307: 30.0.50; pixel-scroll-precision-mode: window-scroll-functions?

[Eli Zaretskii]

> Cc: 61307@debbugs.gnu.org
> Date: Mon, 06 Feb 2023 22:07:55 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Hello,
> >
> > I discovered that when scrolling with the mouse wheel while
> > `pixel-scroll-precision-mode' is enabled `window-scroll-functions' are
> > not run.  Should they be?
> >
> >
> > TIA,
> >
> > Michael.
> 
> IIRC this is due to how pixel-scroll-precision-mode calls
> set-window-start with NOFORCE set to t.
> 
> Patches welcome, but please make sure they do not slow precision
> scrolling down.

We should probably call window-scroll-functions once in several
scrolls, approximately, once every text line worth of scrolling or
something.