Re: Possible support for buffer local idle timers?

[Campbell Barton]

On 9/21/21 02:08, Eli Zaretskii wrote:
> > From: Campbell Barton <ideasman42@gmail.com>
> > Date: Tue, 21 Sep 2021 01:50:47 +1000
> > Cc: emacs-devel@gnu.org
> >
> > > I'm not sure I understand how would that work.  Timers run as part of
> > > the Emacs main command loop, so they are by their nature global.  How
> > > did you imagine that a buffer-local timer would express its "locality"?
> >
> > Yes, the idle timers themselves would be global, but only some buffers
> > would have call-backs registered to run with these timers.
> >
> > Exactly how this works internally is an implementation detail, for the
> > purpose of discussion it could work like this:
> >
> > ;; Setup might look like this.
> > (setq-local my-timer-handle (run-with-idle-timer-local delay t 'my-fn))
> >
> > Internally a pool of repeating timers would be kept, one for each
> > unique delay used by one or more handles, this handle would be created
> > and added to a list of handles associated with this timer.
> > Running the timer would loop over callbacks running them if their
> > buffer matches the current buffer.
>
> So you want such a "buffer-local" timer call its timer function only
> if/when the buffer is the current buffer?  That raises some issues
> that I think would need to be figured out:

Right, there are indeed some wrinkles to figure out... my sense is it's 
only practical to do this if it fits well with the existing global timers.

>    . does the timer start measuring idle time only when the buffer is
>      the current buffer, or regardless of that?

would just go with default behavior of global idle timers since a user 
switching buffers will typically reset idle timers.

>    . what to do when the timer expired but the buffer wasn't current,
>      and then the buffer became current? does the callback gets called
>      right away, or do we "miss" the timer in that case?

default behavior could be to run timers on the previously active buffer 
(instead of missing them), although tracking this information could get 
more involved.

It may be useful for callers to request not to run in the case the 
buffer becomes inactive.

>    . how to handle repeated timers?

As far as I can see repeated timers would be the primary use-case, for 
this feature.

I'm not sure what you mean by "how to handle", all callbacks registered 
to run a repeated buffer local timer could share a timer, this would 
store a list of callbacks which would run each time.

---

It may be that all things considered - there are too many ambiguities 
and corner cases for this to be implemented cleanly.

To be sure of this I think I'd have to attempt to write a small API to 
test if it's practical.

Again, this is meant to be an alternative to packages registering their 
global repeating idle timers that are never removed.
If there are better alternatives to this (such as starting/stopping 
global-idle-timers on switching buffers, perhaps using: 
window-state-change-hook, then that might be better, although even then, 
it may be worth presenting this as a buffer-local-idle-timer API.