Is it planned to remove xemacs compatibility code?

Is it planned to remove xemacs compatibility code?

[CHENG Gao]

Around Emacs code, I find many Xemacs compatibility code as 

(cond ((featurep 'xemacs) blah ...)
(if (featurep 'xemacs) blah ...)

Personally I think these codes should be removed.
And in etc/TODO, I can not find item for remove of these codes.

So I just wonder if it's desired. I think if it's planned, dev team can
post a message or add an item in TODO file. Thus every Emacs user can
submit patch file. After all, this kind of fix is not hard for ordinary
users.

Wish my question is not too dumb.

-- 
德不孤，必有邻
         -- 《论语-里仁》

Re: Is it planned to remove xemacs compatibility code?

[Stefan Monnier]

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

Note that (featurep 'xemacs) is replaced by nil by the byte-compiler.


        Stefan

Re: Is it planned to remove xemacs compatibility code?

[Jay Belanger]

Stefan Monnier <monnier@iro.umontreal.ca> 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?
Also, the manuals of some bundled packages have installation
instructions; should these be kept?

Jay

Re: Is it planned to remove xemacs compatibility code?

[David Kastrup]

Jay Belanger <belanger@truman.edu> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> 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
xemacs-devel@xemacs.org 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
XEmacs.

> 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

Re: Is it planned to remove xemacs compatibility code?

[Adrian Aichner]

David Kastrup <dak@gnu.org> writes:

> Jay Belanger <belanger@truman.edu> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> 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
> xemacs-devel@xemacs.org whether somebody there volunteers to actively

Hi David, make that xemacs-design@xemacs.org and we'll take note :-)

That's a good suggestion!

Best regards,

Adrian

> 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
> XEmacs.
>
>> 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.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: Is it planned to remove xemacs compatibility code?

[Cheng Gao]

,----
| What about the files that aren't distributed separately?
`----
This is what I wonder. For example, "url" package is absorbed in Emacs,
and I dont think it's expected to maintain a Xemacs compatible version
by Emacs developers.

For example, in lisp/term.el, with

(term-if-xemacs ...
(term-ifnot-xemacs ...

all around is really *interesting*, specially term-ifnot-xemacs makes me
nervous. After all, it's a Emacs-bundled file.

Maybe I am too paranoid. 

-- 
我有数行泪
不落十余年
今日为君尽
并洒秋风前

Re: Is it planned to remove xemacs compatibility code?

[Richard Stallman]

    What about the files that aren't distributed separately?

In some cases, there is a person who works on the file and also
supports it for XEmacs, and wants those conditionals to remain.
Or there may be some other specific kind of cooperation with XEmacs
for certain files.  However, where these things do not apply,
they can be deleted.

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

It makes no sense to include these in Emacs; they ought to be deleted.
Would someone like to do that?

Re: Is it planned to remove xemacs compatibility code?

[Stefan Monnier]

> Around Emacs code, I find many Xemacs compatibility code as 
> (cond ((featurep 'xemacs) blah ...)
> (if (featurep 'xemacs) blah ...)

BTW, usually such tests are bad and should instead use
(fboundp <somefunction>) or something like that.


        Stefan