Hideshow

[Hrvoje Niksic]

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

>>    This function returns a timer object which you can use in
>>    `cancel-timer'.
>
>>This means that run-at-time is not standalone.  It requires at least
>>cancel-timer.  And if we have cancel-timer, people will expect the
>>rest of the timer functionality,
>
> Not necessary - IMHO people only expect an senseful to use timer-api not
> necessary a full name- and signature-compatible API

Umm, I don't know about that.  If we name the function the same as an
FSF Emacs function, I think it's up to us to make it behave the same.
After all, I get quite pissed when the FSF people do something like
that to us.  (This happened many times, e.g. with `split-string',
`replace-in-string', with additional arguments to `buffer-substring'
and a bunch of other functions with optional arguments, etc.).

Don't get me wrong, I have nothing against the interfaces being
similar, almost to the point of being compatible -- cf. the
"compatibility" of extent and overlay APIs you spoke of earlier.  I
just think that we should change the naming to avoid confusion.
Identical names should be reserved for fsf-compat-like
reimplementation of foreign APIs.

> Back to your example "run-at-interval":
>
> If such a function would exist i would define a wrapper
> "ecb-run-at-interval" which would use "run-at-interval" for XEmacs
> and "run-with-timer" (or "run-at-time") for GNU Emacs. In addition i
> would define a "ecb-cancle-timer" which deletes the resulting
> itimer- rsp. timer-object suitable. Both is ok and little effort.

That's perfectly fine with me, many programs do that.  The advantage
for us is that we no longer need to exactly reimplement every nuance
of FSF's run-at-time, we only need to implement our API correctly.
That is a much better deal from the implementor's point of view.

In other words, it is then up to your wrapper to ensure that your
program behaves the same under both Emacsen.  And I don't want this to
sound like we're dumping XEmacs maintenance on you: if you happen to
find a bug in our functions, by all means report it and it will get
fixed.  The fsf-compat implementations have the problem that every
deviation from FSF's behavior (which is a moving target itself) can be
considered a bug, and that's just tedious.

> To make a long story short ;-) For me it would be fine if XEmacs
> would offer a timer.el API in the base-package, regardless of the
> names of the contained functions.

I don't completely understand the desire to put timer.el in the base.
It *is* an FSF compatibility package, therefore it does belong to
fsf-compat.  If timer.el really contains functionality not offered by
itimers, we should either add the necessary functionality to itimers
or promote timer.el to a "supported" API, like we did with text
property API's in the past.  I would like to avoid doing the latter
because of all the reasons outlined in
<http://list-archive.xemacs.org/xemacs-beta/200401/msg00456.html>.

Since timer.el normally does a fairly job of emulating the GNU Emacs
behavior (or so I understand), there is no reason to rename its
functions.