unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Campbell Barton <ideasman42@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Possible support for buffer local idle timers?
Date: Tue, 21 Sep 2021 09:07:09 +0300	[thread overview]
Message-ID: <834kae1mya.fsf@gnu.org> (raw)
In-Reply-To: <45045c06-9595-e106-890f-74a25c945876@gmail.com> (message from Campbell Barton on Tue, 21 Sep 2021 10:36:05 +1000)

> Date: Tue, 21 Sep 2021 10:36:05 +1000
> From: Campbell Barton <ideasman42@gmail.com>
> 
> >    . 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 do you mean by "reset timers" here?

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

I don't understand what you mean by "acting on a buffer".  The timer
function can do anything it wants in any buffer.

> >    . 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's related to the second question: if timers don't fire when "their"
buffer is not the current buffer, then repeating timers will
accumulate.  Then it becomes an issue what to do when the buffer
eventually becomes the current one: do we run the timer function N
times or just once?

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

Indeed, I think the idea is not clear enough, and in general timers do
not interact cleanly with the notion of the current buffer, which in
Emacs is very ephemeral.  Emacs switches momentarily to other buffers,
including temporary buffers, a lot, so you could miss a timer tick
very easily due to that.

> Again, this is meant to be an alternative to packages registering their 
> global repeating idle timers that are never removed.

Never removed why? because of bugs?

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

I find the notion of stopping a timer when Emacs switches buffers
strange.  A timer runs with the time, and time does not stop when you
switch buffers.  There's no such notion in Emacs as "buffer-local
time", and if there were, I wouldn't know how to explain its
semantics.  Why does it matter how long was a buffer the current
buffer?



  reply	other threads:[~2021-09-21  6:07 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
2021-09-21  6:07         ` Eli Zaretskii [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=834kae1mya.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ideasman42@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).