Re: undo-auto--undoable-change infloop

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I suspect that `timer-activate` was not intended to be used by
> end-users, but in any case I added a check that signals an error if
> you try to re-add a timer.

I now remember why I am using this.  The scenario is always the same, I
need this in quite a bunch of packages:

I want something happening automatically after certain user interaction
(e.g. scrolling, editing the minibuffer etc), say, running a certain
function F after a delay of DELTA seconds.  When the user does something
before DELTA seconds have passed, the time should count from full DELTA
again - the timer should be postponed.  If it's later, the timer should
be started anew (unless the "scenario" had been left).

In the code, I can't be certain whether the timer had been triggered (at
least without consulting "internal" information).  In any case the timer
still exists as a timerp fulfilling object (it's the value of some
variable I use).  So I used `timer-set-time' to update the preferred run
time and called `timer-activate' to ensure it's in the list (to cover
the second case: timer had been run).  And, as we had found out, that is
wrong when the timer is actually still in the list.

Is there a way to achieve what I want without relying on "internal data"
(like looking in `timer-list')?

Michael.