[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: timer.el API
From: |
Michael Heerdegen |
Subject: |
Re: timer.el API |
Date: |
Mon, 03 Oct 2022 22:59:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> And its effect is very poorly defined in its docstring. So whichever
> behavior we choose for it, I'm sure someone can come up with
> a legitimate case where that precise behavior is indeed needed.
Madhu wrote:
> The idea was to handle a "mode" where keystrokes would enter characters
> in a "search string". the "mode" would timeout after a 10 seconds. If a
> new character of the "search string" is read within the timeout period,
> the timer is renewed ("respooled"). If a non "search string" character
> is read, then the timer is cancelled and the "mode" exits.
This is exactly the scheme I need now and then, and the only kind of
task where I wanted `timer-activate'.
> Someoneā¢ should probably take a step back, decide what the exposed API
> *should* be, rename the rest to use internal names, and then add
> obsolete aliases to temporarily preserve backward compatibility.
Maybe renaming `timer-activate' to `timer--activate' and implementing a
solution for the above kind of requirement would already be a big part
of the way?
Michael.
- Re: timer.el API,
Michael Heerdegen <=