Hideshow

[Hrvoje Niksic]

"Berndl, Klaus" <klaus.berndl at sdm.de> writes:

> before i knew start-itimer i would have said: "Yes, itimer.el a
> low-level thing which is hard to use without a higher abstraction
> level."... But now - after knowing start-itimer i say "No, itimer
> has almost all what one needs to program conventiantly with timers"

:-)

> the only thing needed would be something like `run-at-time'.
[...]

>>Does [your finding] mean that start-itimer removes the need for a
>>run-at-time clone?
>
> At least it removes the need for functions like run-with-timer or
> run-with-idle-timer because if i understand the docstring of
> start-itimer right the following is true:
>
> (run-with-timer 5 1 'ignore 'bla 'bla 'bla) is the same as
> (start-itimer "my-timer" 'ignore 5 1 nil nil 'bla 'bla 'bla)
>
> and
>
> (run-with-idle-timer 5 1 'ignore 'bla 'bla 'bla) is the same as
> (start-itimer "my-timer" 'ignore 5 1 'idle nil 'bla 'bla 'bla)
>
> Right?

I suppose so.  I am not knowledgable about the timing API's, but in my
past experience, itimer.el is well documented and free of bugs.  Feel
free to try it out and see if it works for your package.

> `run-at-time' is IMO not implemented in current itimer.el so this
> function should be added, of course with another name ;-)

OK.  We should propose an itimer variant of run-at-time on
xemacs-design.

Thanks for your patience.