all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Campbell Barton <ideasman42@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Possible support for buffer local idle timers?
Date: Tue, 21 Sep 2021 10:36:05 +1000	[thread overview]
Message-ID: <45045c06-9595-e106-890f-74a25c945876@gmail.com> (raw)
In-Reply-To: <83ee9j1b7z.fsf@gnu.org>

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.



  reply	other threads:[~2021-09-21  0:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 13:49 Possible support for buffer local idle timers? Campbell Barton
2021-09-20 15:30 ` Eli Zaretskii
2021-09-20 15:50   ` Campbell Barton
2021-09-20 16:08     ` Eli Zaretskii
2021-09-21  0:36       ` Campbell Barton [this message]
2021-09-21  6:07         ` Eli Zaretskii
2021-09-21  6:16           ` Lars Ingebrigtsen
2021-09-21 10:19           ` Campbell Barton
2021-09-21 10:43             ` Eli Zaretskii
2021-09-25  7:26               ` Campbell Barton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45045c06-9595-e106-890f-74a25c945876@gmail.com \
    --to=ideasman42@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.