Re: Sending attachments

[Stephen J. Turnbull]

Frank Schmitt writes:

 > Is XEmacs compatibility really worth the trouble? How many XEmacs users
 > are still out there?

First, XEmacs compatibility is not usually that great a burden.
Certainly, when you're trying to support bleeding edge features (viz.
preview-latex), you run into problems.  But mostly the work is already
done, and with a few exceptions where XEmacs led Emacs by 5 to 10
years in introducing an API and Emacs deliberately varied, we do
(eventually) sync by adding the feature with the Emacs-style APIs.

Second, there are still plenty of XEmacs and SXEmacs users to justify
*keeping* existing features.  Several GNU/Linux distros have tried to
drop XEmacs packages or deemphasize them in one way or another, and
gotten *strong* pushback from their users.  XEmacs also still has a
strong following in two large companies that I know of, I believe
because they consider it much easier to maintain local extensions to
XEmacs.  They don't even try with Emacs.  I have to think that there
are a lot of such users out there, who probably don't participate much
in free software channels, they just use it.

There's also the question of *contributors* vs. users.  XEmacs (and
even more so, SXEmacs) contributors have been quite loyal, due to the
large investment required to work on internals of any Emacsen.  So
making XEmacs less usable would quite likely result in a loss of
developers to the entire community rather than a flow of developers to
Emacs proper.

Anyway, the question is if merging Gnus code into Emacs would result
in a purge of XEmacs compatibility code.  Sometimes Richard uses
expressions that suggest that might happen, but AFAICT his opinion on
the matter is that he thinks mixing XEmacs compatibility code with
application implementation is unclean, and he advocates *separating*
them out.  Of course if XEmacs compatibility modules are not going to
be maintained, he prefers them to be dropped, and I'm sure he'd prefer
that the effort be devoted to Emacs proper -- but after all, that's
the contributor's choice.