Support for explicitly resetting the idle timer?

Support for explicitly resetting the idle timer?

[Campbell Barton]

Hi, I've run into a situation where being able to reset the idle time is 
needed. As far as I can tell there is no way to do this at the moment.
So I'm writing to check if a patch to support this is likely to be 
considered.

To give some context for how I ended up needing this, the motivation for 
this is noted below.


Motivation
==========

There is a package I use/maintain which implements something like 
Firefox's auto-scroll (click-drag to scroll up/down) [0].

An issue with this is (unlike mouse wheel scrolling) using track-mouse 
doesn't handle keyboard events in a way that resets the idle timer.

So while scrolling, idle timers may run (which can cause visible 
stuttering).

I've worked around this by locally let binding `timer-idle-list` to nil, 
however this back-fires if any timers are added while scrolling (rare 
but possible), workarounds for this are possible - but they involve 
clearing the list while scrolling then moving the contents into the real 
`timer-idle-list` list... which as far as I can see is quite error 
prone, especially if packages are inspecting the contents of this list.

All this complexity could be avoided if the function `timer_stop_idle` 
in ./src/keyboard.c was exposed to elisp, this way scripts that use 
mouse input could explicitly reset the idle timer on mouse based 
user-interaction (when it makes sense).

Other solutions could work too (perhaps something specific to 
`track-mouse`), but I think having a way to reset the idle timer is most 
straightforward.

[0]: https://gitlab.com/ideasman42/emacs-scroll-on-drag

Re: Support for explicitly resetting the idle timer?

[Eli Zaretskii]

> Date: Sat, 27 Nov 2021 18:54:56 +1100
> From: Campbell Barton <ideasman42@gmail.com>
> 
> There is a package I use/maintain which implements something like 
> Firefox's auto-scroll (click-drag to scroll up/down) [0].
> 
> An issue with this is (unlike mouse wheel scrolling) using track-mouse 
> doesn't handle keyboard events in a way that resets the idle timer.
> 
> So while scrolling, idle timers may run (which can cause visible 
> stuttering).
> 
> I've worked around this by locally let binding `timer-idle-list` to nil, 
> however this back-fires if any timers are added while scrolling (rare 
> but possible), workarounds for this are possible - but they involve 
> clearing the list while scrolling then moving the contents into the real 
> `timer-idle-list` list... which as far as I can see is quite error 
> prone, especially if packages are inspecting the contents of this list.
> 
> All this complexity could be avoided if the function `timer_stop_idle` 
> in ./src/keyboard.c was exposed to elisp, this way scripts that use 
> mouse input could explicitly reset the idle timer on mouse based 
> user-interaction (when it makes sense).

The cleanest solution in this case would be to call timer_stop_idle if
Emacs is executing a command, no matter how it was invoked.  In fact,
I'm surprised that we don't stop idle timers when track-mouse invokes
commands: it sounds like a bug we should fix.

Re: Support for explicitly resetting the idle timer?

[Campbell Barton]

On Sat, Nov 27, 2021 at 7:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Sat, 27 Nov 2021 18:54:56 +1100
> > From: Campbell Barton <ideasman42@gmail.com>
> >
> > There is a package I use/maintain which implements something like
> > Firefox's auto-scroll (click-drag to scroll up/down) [0].
> >
> > An issue with this is (unlike mouse wheel scrolling) using track-mouse
> > doesn't handle keyboard events in a way that resets the idle timer.
> >
> > So while scrolling, idle timers may run (which can cause visible
> > stuttering).
> >
> > I've worked around this by locally let binding `timer-idle-list` to nil,
> > however this back-fires if any timers are added while scrolling (rare
> > but possible), workarounds for this are possible - but they involve
> > clearing the list while scrolling then moving the contents into the real
> > `timer-idle-list` list... which as far as I can see is quite error
> > prone, especially if packages are inspecting the contents of this list.
> >
> > All this complexity could be avoided if the function `timer_stop_idle`
> > in ./src/keyboard.c was exposed to elisp, this way scripts that use
> > mouse input could explicitly reset the idle timer on mouse based
> > user-interaction (when it makes sense).
>
> The cleanest solution in this case would be to call timer_stop_idle if
> Emacs is executing a command, no matter how it was invoked.  In fact,
> I'm surprised that we don't stop idle timers when track-mouse invokes
> commands: it sounds like a bug we should fix.

Not sure if this would solve my case (is there some formal definition
of what is meant by a command?).
I'm changing the scroll position using `set-window-vscroll` - so I'm
not sure if that counts as a command.
As a workaround it may be possible to define a dummy command that does
nothing but reset the idle timer.

-- 
- Campbell

Re: Support for explicitly resetting the idle timer?

[Eli Zaretskii]

> From: Campbell Barton <ideasman42@gmail.com>
> Date: Sat, 27 Nov 2021 19:42:15 +1100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > The cleanest solution in this case would be to call timer_stop_idle if
> > Emacs is executing a command, no matter how it was invoked.  In fact,
> > I'm surprised that we don't stop idle timers when track-mouse invokes
> > commands: it sounds like a bug we should fix.
> 
> Not sure if this would solve my case (is there some formal definition
> of what is meant by a command?).
> I'm changing the scroll position using `set-window-vscroll` - so I'm
> not sure if that counts as a command.

Which code invokes set-window-vscroll, and what triggers that code?

> As a workaround it may be possible to define a dummy command that does
> nothing but reset the idle timer.

Btw, what do you mean by "reset" here?  timer_stop_idle has a
counterpart, timer_resume_idle.  Would the resumption work under your
proposal, and if so, how?

Re: Support for explicitly resetting the idle timer?

[Campbell Barton]

On Sat, Nov 27, 2021 at 8:01 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Campbell Barton <ideasman42@gmail.com>
> > Date: Sat, 27 Nov 2021 19:42:15 +1100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > > The cleanest solution in this case would be to call timer_stop_idle if
> > > Emacs is executing a command, no matter how it was invoked.  In fact,
> > > I'm surprised that we don't stop idle timers when track-mouse invokes
> > > commands: it sounds like a bug we should fix.
> >
> > Not sure if this would solve my case (is there some formal definition
> > of what is meant by a command?).
> > I'm changing the scroll position using `set-window-vscroll` - so I'm
> > not sure if that counts as a command.
>
> Which code invokes set-window-vscroll, and what triggers that code?

There is a while loop that uses  (read-event) inside a `(track-mouse
...)` block that changes the scroll location and redraws.

(any solution shouldn't be so specific to my use-case of course,
AFAICS it's just a case that is reasonable to support with whatever
fix/feature is used).

> > As a workaround it may be possible to define a dummy command that does
> > nothing but reset the idle timer.
>
> Btw, what do you mean by "reset" here?  timer_stop_idle has a
> counterpart, timer_resume_idle.

I've probably misunderstood the purpose of this function, I only meant
to reset the idle timer (as already happens when a key has been
pressed).

> Would the resumption work under your proposal, and if so, how?

Yes, resuming is would be fine,
I considered some alternative solution too, e.g. a
`(without-idle-timers ...)` macro - which would be useful in my case -
but doesn't seem necessary if the idle timer can be reset either
explicitly or automatically in more cases than it is currently being
done.
-- 
- Campbell

Re: Support for explicitly resetting the idle timer?

[Eli Zaretskii]

> From: Campbell Barton <ideasman42@gmail.com>
> Date: Sat, 27 Nov 2021 20:14:44 +1100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > > Not sure if this would solve my case (is there some formal definition
> > > of what is meant by a command?).
> > > I'm changing the scroll position using `set-window-vscroll` - so I'm
> > > not sure if that counts as a command.
> >
> > Which code invokes set-window-vscroll, and what triggers that code?
> 
> There is a while loop that uses  (read-event) inside a `(track-mouse
> ...)` block that changes the scroll location and redraws.

But that while loop is invoked by some binding of some mouse gesture,
no?  That binding _is_ the "command" I meant.

> (any solution shouldn't be so specific to my use-case of course,
> AFAICS it's just a case that is reasonable to support with whatever
> fix/feature is used).

Any solution that makes sure idle timers don't run when Emacs executes
a command is not specific to any use case, IMO.

Re: Support for explicitly resetting the idle timer?

[Campbell Barton]

On Sat, Nov 27, 2021 at 9:10 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Campbell Barton <ideasman42@gmail.com>
> > Date: Sat, 27 Nov 2021 20:14:44 +1100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > > > Not sure if this would solve my case (is there some formal definition
> > > > of what is meant by a command?).
> > > > I'm changing the scroll position using `set-window-vscroll` - so I'm
> > > > not sure if that counts as a command.
> > >
> > > Which code invokes set-window-vscroll, and what triggers that code?
> >
> > There is a while loop that uses  (read-event) inside a `(track-mouse
> > ...)` block that changes the scroll location and redraws.
>
> But that while loop is invoked by some binding of some mouse gesture,
> no?  That binding _is_ the "command" I meant.

Ah, right. There is an interactive function bound to a key which runs
track-mouse ... etc.
>
> > (any solution shouldn't be so specific to my use-case of course,
> > AFAICS it's just a case that is reasonable to support with whatever
> > fix/feature is used).
>
> Any solution that makes sure idle timers don't run when Emacs executes
> a command is not specific to any use case, IMO.

Okay, that makes sense then, yes - it seems reasonable.

Arguments could be made against this:

- This could break existing packages that use long running commands
and expect the idle timer to run.
- Any developer running into this situation in the future (idle timers
and track-mouse that is) - might reasonably expect idle timers to
activate when the user isn't moving the mouse.

However if the change in behavior is acceptable by emacs developers,
I'm not pushing against it - just noting some possible down-sides.

-- 
- Campbell

Re: Support for explicitly resetting the idle timer?

[Eli Zaretskii]

> From: Campbell Barton <ideasman42@gmail.com>
> Date: Sat, 27 Nov 2021 21:21:29 +1100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > > > Which code invokes set-window-vscroll, and what triggers that code?
> > >
> > > There is a while loop that uses  (read-event) inside a `(track-mouse
> > > ...)` block that changes the scroll location and redraws.
> >
> > But that while loop is invoked by some binding of some mouse gesture,
> > no?  That binding _is_ the "command" I meant.
> 
> Ah, right. There is an interactive function bound to a key which runs
> track-mouse ... etc.

So now I wonder how come the idle timers run for you.  Perhaps the
command you mention activates track-mouse and exits?

> Arguments could be made against this:
> 
> - This could break existing packages that use long running commands
> and expect the idle timer to run.

While a command's code runs, idle timers cannot run, because timers
only run when Emacs is in its idle loop, waiting for some input.
Emacs only gets to the idle loop after a command exits and there's no
further input waiting for processing.

Re: Support for explicitly resetting the idle timer?

[Campbell Barton]

On Sat, Nov 27, 2021 at 9:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Campbell Barton <ideasman42@gmail.com>
> > Date: Sat, 27 Nov 2021 21:21:29 +1100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > > > > Which code invokes set-window-vscroll, and what triggers that code?
> > > >
> > > > There is a while loop that uses  (read-event) inside a `(track-mouse
> > > > ...)` block that changes the scroll location and redraws.
> > >
> > > But that while loop is invoked by some binding of some mouse gesture,
> > > no?  That binding _is_ the "command" I meant.
> >
> > Ah, right. There is an interactive function bound to a key which runs
> > track-mouse ... etc.
>
> So now I wonder how come the idle timers run for you.  Perhaps the
> command you mention activates track-mouse and exits?

It also seems strange to me, but it's not exiting - it runs
track-mouse and calls read-event & redisplay, just double checked -
idle timers are definitely running inside the track-mouse block (which
is within the command).

> > Arguments could be made against this:
> >
> > - This could break existing packages that use long running commands
> > and expect the idle timer to run.
>
> While a command's code runs, idle timers cannot run, because timers
> only run when Emacs is in its idle loop, waiting for some input.
> Emacs only gets to the idle loop after a command exits and there's no
> further input waiting for processing.

It's possible there is something more specific to my package than I
realized (although I'm not sure what as it's basically re-displaying
in a loop).

-- 
- Campbell

Re: Support for explicitly resetting the idle timer?

[Eli Zaretskii]

> From: Campbell Barton <ideasman42@gmail.com>
> Date: Sat, 27 Nov 2021 22:16:10 +1100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > > Ah, right. There is an interactive function bound to a key which runs
> > > track-mouse ... etc.
> >
> > So now I wonder how come the idle timers run for you.  Perhaps the
> > command you mention activates track-mouse and exits?
> 
> It also seems strange to me, but it's not exiting - it runs
> track-mouse and calls read-event & redisplay, just double checked -
> idle timers are definitely running inside the track-mouse block (which
> is within the command).

Probably because your command calls read-event, which re-enters the
input processing loop, and can wait for input.