"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
David> It is certainly more than enough trouble for me trying to
David> try to keep the stuff I maintain basically running with
David> XEmacs. I certainly won't volunteer for more. As it is,
David> XEmacs is already causing me more work than I'd care for.
It's possible it would be _less_ work than dealing with (for example)
regular bug reports from people using old versions of AUC-TeX on
XEmacs, and people trying to set up preview-latex on XEmacs without a
The package system is not powerful enough to deal with all settings
those packages work under. You might have wildly different TeX
distributions with their own directory components, you have different
GhostScript executable names, you have different ways of adding local
TeX styles and so forth and so on. preview-latex's installation is
./configure; make; make install
on all systems (where you need a few more options when you are not
kpathsea based). Of course, this has the disadvantage of requiring a
toolset being able to run autoconf.
There is no package system for GNU Emacs, and I am not abandoning GNU
Emacs support. Having to cater for a package based install thus is
more work. Either somebody else does it or it does not get done,
David> I'd so this, if at all, on a strictly tit for tat
David> somebody implement a well-working package system for both
David> Emacs and XEmacs, and packages will appear.
Implementation is done, and you know that, David. Getting the UI
and maintenance infrastructure into GNU Emacs is not under our
From what I have heard, the author of the XEmacs package system is
working on replacing it by yet something different which would then
again make the version taken into GNU Emacs obsolete.
Also, if there is going to be any sense in the operation, it would
need to be done in a way to make packages possible that work with both
Emacs and XEmacs. I don't see that. The venture only makes sense to
me if it means I can create packages that will work on both systems.
This means, of course, that byte compilation should happen at
installation time, as well as weeding out unneeded package parts for
the particular Emacs. It would be a boon to be able to keep files
that are not Emacs-version-specific in common subdirectories. In this
case, you would need to update packages in sync, which might not be
feasible at all times. So this should be optional, and probably is
not really that much of importance.
In short: a port that will make Emacs have something similar but
incompatible to XEmacs does not help people in the long run.
The idea is to make less work, not more.
David Kastrup, Kriemhildstr. 15, 44793 Bochum