David Kastrup writes:
version dependencies. I know from AUCTeX that it has been an
absolute pain to provide compatibility with Emacs 20.4(?) APIs
because XEmacs has not bothered keeping up.
It's more than a "bother" to keep up; it's illegal. Until we get the
GPLv3 stuff nailed down, which is slowly coming along.
Lagging 5 to 10 years behind the core usability
Oh, come on, David. Lagging 5 to 10 years behind core usability
doesn't bother you at all when it's XEmacs that is ahead.
I don't blame you for wanting a single Emacs API to target, but don't
blame us because some of your users still prefer XEmacs despite an
alleged 5 to 10 year lag. As always, it's your choice what to
support, and I've been reminding you of that fact for many years now.
I will remind you that Richard and Stefan do not have your qualms
about supporting old versions of anything. They support only the
current release (and for some definitions of "support", the
development code). Stefan's reasonable about adopting XEmacs practice
in many cases, but he doesn't care about compatibility enough to do it
any way but the way he thinks best. I'm pretty sure that he and
Yidong will deal with integrating CEDET etc in the same way.
That's not my bet. Emacs is still on its forward path to
providing
a consistent IDE and that means advancing forward on several fronts
at once in a more or less interlocked manner.
Fine. Keep the parts that the IDE depends on in core at least until
the APIs settle down, and maybe forever if the IDE stuff turns out to
be mission-critical to all Emacs users. I don't think that should
include Gnus, calc, calendar, and maybe not even org-mode, though.
Just moving Gnus and calc out of the core distribution would make a
huge difference in time to bootstrap.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta