Hideshow

[Berndl, Klaus]

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

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

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

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!
Klaus