From xemacs-m  Fri May 23 17:37:34 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA17885
	for <xemacs-beta@xemacs.org>; Fri, 23 May 1997 17:37:33 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id AAA15267; Sat, 24 May 1997 00:37:30 +0200 (MET DST)
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: timer code
References: <kigaflmrpa3.fsf@jagor.srce.hr> 	<m2wwoqm1fr.fsf@altair.xemacs.org> 	<QQcqux17889.199705231949@crystal.WonderWorks.COM> 	<kig7mgqrm8b.fsf@jagor.srce.hr> <QQcqvf19395.199705232146@crystal.WonderWorks.COM>
X-Save-Project-Gutenberg: <URL:http://www.promo.net/pg/nl/pgny_nov96.html>
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
X-Tom-Swifty: "My feet hurt," Tom said pedantically.
From: Hrvoje Niksic <hniksic@srce.hr>
In-Reply-To: Kyle Jones's message of Fri, 23 May 1997 17:46:10 -0400 (EDT)
X-Mailer: Gnus v5.4.52/XEmacs 20.2
Date: 24 May 1997 00:37:29 +0200
Message-ID: <kig206xstli.fsf@jagor.srce.hr>
Lines: 76

Kyle Jones <kyle_jones@wonderworks.com> writes:

>  > I disagree.  If people use the undocumented features, they'll get
>  > garbage in XEmacs (and possibly in later versions of GNU Emacs).
>  > But if we require them to use a completely divergent interface in
>  > XEmacs, the situation is much worse.
> 
> Heh, well, they could have used my interface.

But it's not bundled with GNU Emacs, so they didn't.  Yes, I foresee a 
number of your responses to this, but please refrain -- this is no
place to discuss FSF vs. Lucid issues.

>  > Do we really want to collect this cruft in the form of GNU
>  > Emacs-compatible packages?
> 
> Why not?

Because it's ugly, repeating and error-prone.  If we have versions of
these functions that at least we know *work*, why not provide them?

> For non-trivial packages such functions have to be collected anyway.
> The argument you're making might have been valid before 19.12 was
> released (and I'm sure I made it back with regard to other things),
> but source level compatibility is almost a moot point now.  Done is
> done.

Can you clarify?  Source level compatibility seems to work for Gnus,
and a number of other packages.  All I'd like to see is the ugly
crufty hand-made interface be changed to something we create.

> in the distribution.  At least not today.  Tomorrow I might be
> back on my medication and feel differently!  :-)

Well, I realize that, but it seems a little-bit relying on chance to
wait until you do. :-)

Anyways, I'm not even sure how this discussion started.  I thought we
were only waiting for XEmacs 20.3 to come for this code to be
introduced.  Noone (including yourself) ever mentioned anything like
this.

> Shipping timer.el opens us up to more "your stuff doesn't work like
> FSF Emacs so you suck" yammerings.  Well, no thanks, I'm full!  Let
> them use the interface we've had all along.

This would be a valid point, if the situation between us and the FSF
were reverse.  However, there are a lot more FSF Emacs programmers
than XEmacs programmers at the moment.  We are the ones who should be
attracting new people by being all fine and ready-to-help, and
offering them features, so they come to us and stay with us; Stallman
has never been like that anyway.

One of the good ways to attract GNU Emacs programmers is to say "you
see, we have not only all of this cool new stuff, but we try hard to
be compatible with X, Y and Z, so that it's easier for you guys."
Definitely sounds better than "use the interface we've had all along."

>  > I don't think "incompatible and unrepentent" is the right course
>  > of action, when we can do better.  If a large amount of code yet
>  > had to be written, I'd understand your feelings.  But not
>  > including an already written package has no excuse -- except
>  > maybe the path of the least resistance, and I don't think we
>  > should cater to that.
> 
> My point is that we have a well-defined, well established interface
> and FSF Emacs doesn't.  Why invite trouble?

Because we want not only to have the interface, but the users, too.  I 
don't feel satisfied with a prospect of having a fine and incompatible 
interface of our own, with the programmer-base close to 0.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

