xemacs vs emacs
dak at gnu.org
Mon Apr 7 15:46:10 EDT 2008
Reiner Steib <reinersteib+gmane at imap.cc> writes:
> [ The following message is a courtesy copy of an article that has
> been posted to news:gmane.emacs.xemacs.beta as well. ]
> On Sun, Apr 06 2008, Stephen J. Turnbull wrote:
>> How much hope do you have that Emacs 23 will be released in less
>> than 5 years,
> Personally, I'm confident that the new maintainers (Stefan Monnier and
> Chong Yidong) will manage to release faster.
Well, 22.2 has already been released. 22.3 does not sound like being
all too far off, either.
>> > AUCTeX
>> AUCTeX is a special case; the AUCTeX project maintainer objects to
>> the XEmacs package system in principle
> I don't speak for David, but I think he objects to outdated packages
> and some of the policies, not to the system itself. (But we had more
> than enough discussion about this on this list already.)
Oh puleeze! The _only_ party that is _objecting_ to AUCTeX trying to
support XEmacs are the XEmacs core team. They don't accept our package
They demand that we have to scrap our own package build and directory
structure and adapt the XEmacs style of installing packages (never mind
that this is much less versatile) and that we become active XEmacs
developers with CVS access to the package archive and do all of the
integration work into the XEmacs package system in order to be _allowed_
to distribute AUCTeX with XEmacs.
I am not interested in doing all that extra work in order to
artificially arrive at the status quo we already have, a working XEmacs
package. I've repeatedly given plenty of help and advice to anybody who
believed this to be a worthwhile task.
So I am guilty of not investing every amount of work that the XEmacs
cabal is _demanding_ so that they don't need to adapt their "quality
control" policies to reality.
And if I don't do all that work they want done from me in order to save
themselves having to either think or code, they will badmouth me on the
developer list and berate me for my "unwillingness to support" XEmacs or
similar idiocies and clamor over my "objections".
I repeat: the only objections about XEmacs support I ever made were to
AUCTeX developers who wanted to drop XEmacs support. At some point of
time I might give in and no longer object against this stupid uphill
battle. Not yet.
Sure: I don't volunteer my time to spend as the XEmacs team feels fit to
demand. I am not interested in XEmacs myself. I will help people get
off the ground where I can, those who _are_ interested in XEmacs and
willing to support it with more than just flaming.
Few remain seemingly.
But that's not my problem. As long as there is anybody willing to do
the work, he gets all what can reasonably be expected from me and then
I have invested a lot of developer time for XEmacs. I have myself alone
spent at least three man-months for preview-latex integration into
XEmacs, and at least a month for getting the build structure and
internal package structure for XEmacs right.
What I get in return is ostracization of the package we produce and
tirades on the XEmacs list what a bad person I am for objecting to
supporting XEmacs and similar crap.
I don't think I ever encountered _any_ project where I received so much
bad vibration and abuse and obstruction at every turn for so much
invested work. We are literally supporting AUCTeX on XEmacs in
opposition and in spite of the XEmacs team rather than because of or
And people just refuse to get it into their heads that I am not the one
blocking the inclusion of the existing AUCTeX package for XEmacs into
the package system.
We went all the nine yards to support XEmacs. But somebody will have to
go all the nine yards again, in the manner prescribed by the XEmacs
ruling council in order to arrive at _exactly_ the same place.
This is silly, but that is not my problem. I won't stop anybody else
from doing that, and he gets my advice and goodwill and help. I am not
myself doing the same work in the "superior" XEmacs way (that has not
for years found somebody able to actually produce a working XEmacs
package). But I am also not standing in anybody else's way.
David Kastrup, Kriemhildstr. 15, 44793 Bochum
More information about the XEmacs-Beta