[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it planned to remove xemacs compatibility code?

From: David Kastrup
Subject: Re: Is it planned to remove xemacs compatibility code?
Date: Tue, 26 Oct 2004 23:00:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

Jay Belanger <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>>> Around Emacs code, I find many Xemacs compatibility code as
>>> (cond ((featurep 'xemacs) blah ...)
>>> (if (featurep 'xemacs) blah ...)
>> Those files are typically also distributed separately from Emacs
>> for older Emacsen or for XEmacs, so it is better to keep this code
>> so as to minimize the difference between the version bundled with
>> Emacs and the other version: any difference tends to lead to
>> problems keeping the files in sync.
> What about the files that aren't distributed separately?

As long as we don't get big amounts of unmaintable cruft and as long
as there is some reasonable chance that the code will help the XEmacs
developers catch up with it, I'd leave it in.  If one thinks that the
stuff is falling into bit rot anyway, it may be an idea to ask on the
address@hidden whether somebody there volunteers to actively
keep it working inside of the Emacs CVS (requires copyright
assignment).  If not, it is probably saner to just pull it instead of
giving the XEmacs crowd something that only pretends to work with

> Also, the manuals of some bundled packages have installation
> instructions; should these be kept?

As long as we are maintaining the manuals separately, I don't see any
point in including either installation instructions for Emacs or
XEmacs, if the respective version of the package is already installed
with Emacs.  If there is no manual available outside of the Emacs CVS,
this is probably a situation that is a bit unfortunate.  Again, I'd
then ask on the XEmacs list whether somebody wants to maintain the
respective section (which can probably be removed by conditional
compilation) here, and pull it only if nobody can be found willing to
maintain those parts.  Keeping possibly outdated and incorrect
documentation around will help nobody.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]