klaus.berndl at sdm.de
Fri Feb 6 09:27:22 EST 2004
>> Correctly and in addition with a layer which offers the most often
>> used and most important tasks of the API in form of some few
>> easy-and-conveniant-to-use functions. If you mean this with the term
>> "correctly" then i fully agree.
>I'm not sure I'm getting the point here. Let me see if I understood
>It sounds like you perceive the itimer API as a low-level thing which
>is hard to use without a higher abstraction level. I'm pretty sure
>that its author did not intend it as such. In other words, if you
>feel that something is missing from the API, you should by all means
>ask for it. (In fact, you did ask for run-at-time, but that function
>requires the whole timer.el API, hence my run-at-interval
>counter-suggestion.) That goes not only for the itimer API, but for
>other things, such as extents, keymaps, specifiers, menus, etc.
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'.
>Did I understand you correctly?
see above ;-)
>> Oops, sorry, my fault, i have expressed this misunderstanable. What
>> i wanted to say is exactly what you have answered. I meant to put
>> the *functionality* not the *compatibility* of timer.el into some
>> not-fsf-compat-package. So to speak with our example of
>> "run-at-interval": Such a function should be added to itimer.el.
>We might want to move that proposal to `xemacs-design'. The
>implementation should be simple -- simply take timer.el's run-at-time,
>but implement it using itimers directly, and have it return the
>itimer. I'm not sure if Kyle Jones, author of itimer, reads these
>lists, so we might want to Cc him for suggestions.
Yes, maybe a good idea...
>> BTW: I just saw the function start-itimer which is pretty much an
>> one-function-easy-to-use-on-top-layer over itimer.el.
>Does it mean that start-itimer removes the need for a run-at-time
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)
(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)
`run-at-time' is IMO not implemented in current itimer.el so this function
should be added, of course with another name ;-)
>> Unfortunatelly there is no info-manually for itimers which points me
>> to that function.
>Sorry about that. itimer originated as a third-party package to add
>interval timer functionality to XEmacs, and became "official" much
>later. Noone got around to documenting it properly. Until this is
>done, `M-x apropos RET itimer RET' is the most readily available
Yes, sure, you are right - but often proper info-manuals are needed to
learn the underlying design- and usage-principle of a mechanism. I admit
itimers should be understandable also without such a manual - if one knows
the existence of start-itimer - but this should be manageable by every XEmacs-user... next time i will use apropos...
So we came to a conclusion like often in such discussion: If i would have used `apropos' then i would have found `start-itimer' then i would not have cried so loudly for a better usable itimer.el package <blush> ;-)
Ok, if something like `run-at-time' would be added to itimer then we all would be very happy and there would be (IMHO) no longer a need for fsf-compat because:
- handling extends/overlay is in most cases simple
- instaed of thing-at-point i can use the stuff of thing.el (which works
well for my needs)
- and for timers...hmmm, see above ;-)
Thanks for discussing with me!
More information about the XEmacs-Beta