James LewisMoss writes:
> I am taking over package management for XEmacs 19.14 from Darren, and
> also planning on putting out XEmacs 20.0. (this is my first time
> doing this so it is taking me a bit :)
>
> I'm planning on allowing both v19 and v20 XEmacs to be installed.
> XEmacs will be compiled with mule support, and while some people will
> want it I assume others will not want it (it slows down XEmacs a
> noticeable amount, so I figured the choice would be better). XEmacs
> 20.0 without mule support is actually faster than 19.14, but figuring
> out how to deal with that is a little beyond me at the moment (and
> 19.15 should be faster than 20.0 without mule, so it'll be better when
> that is released).
>
> The only hitch I still haven't figured out is dealing with package
> installed .el files in /usr/lib/emacs/site-list. I don't feel it is
> right to just add that directory to the load path because there are
> enough difference between GNU Emacs and XEmacs that it might cause
> problems (esp v20 and GNU Emacs). My current though is to deal with
> one .el file (debian-changelog-mode.el since I am using that), and let
> the rest be dealt with locally if the local person wants to. (though
> this is a bad solution I must admit). Does anyone have any
> suggestions?
>
> Does anyone have an general suggestions/comments/thoughts/concerns/etc?
>
There are several issues touched by this problem:
[ Both Emacs 19.34 and XEmacs are GNU Emacs, so I call the former just
Emacs, the later XEmacs]
1) The main problem is that XEmacs (19.14) cannot read Emacs (19.34)
byte-compiled lisp files, while Emacs can in fact read XEmacs
compiled .elc files. If you want to have a directory containing
lisp files for both of them (it certainly is possible to support
both variants in a single lisp file), you have to ensure that only
XEmacs is used for byte-compiling.
This could be ensured by using a shell script, say
emacs-byte-compile that will use XEmacs if installed and Emacs
otherwise). Every package that uses byte-compiling must use this
shell script.
2) there are several packages that are neither part of Emacs nor of
XEmacs. Currently those packages are only available for Emacs, not
for XEmacs (e.g. auctex or tm). To use them with XEmacs you need to
hack the packages, although both packages support both variants of
GNU Emacs. There are basically two ways to handle this:
a) make two debian packages, each supporting a single variant of
GNU Emacs. Advantage: simple, easy to maintain
Disadvantage: cluttering up of package namespace and unnecessary
use of disk space.
b) use a single debian package to support both Emacsen using a
special directory added to the load path of both
(e.g. /usr/share/emacs/packages). The package has to be compiled
either at installation time (using the script mentioned above)
or has to be built using XEmacs. The later method has the
disadvantage that every package maintainer building a package
including byte-compiled must have XEmacs installed.
Advantage: no namespace or disk space cluttering.
Disadvantage: use of a non-standard element in both load paths,
more complicated for package maintainers.
3) There is a lot of functionality in elisp packages that is included
in some add-ons for emacs while being part of the main xemacs
distribution. This should not be needed as it is possible (at least
for some packages) to be used by both XEmacs and Emacs. An example
for this is vm. As XEmacs 19.15 will come in an unbundled form as
well as the current kitchen sink distribution, this problem will be
basically the same as the one above. So I propose to leave this
problem alone until XEmacs 19.15 is released.
4) single elisp files or packages that are not to be compiled
definitely should be in the load path of both Emacsen. This
includes e.g. debian-changelog-mode.el. If there are problems with
compatibility on the elisp level, they should be fixed on that level.
(elisp is perfectly capable of distinguishing between Emacs
versions and variants). So I will go even further than simply
including /usr/lib/emacs/site-lisp in the load path of XEmacs by
proposing there should be a single site-lisp directory used for
both Emacs variants.
Once debian changes from using FSSTND to the (hopefully soon
released) FHS it will be clear where this directory is to be:
/usr/share/emacs/site-lisp. Until then I suggest using the Emacs
location /usr/emacs/site-lisp for both XEmacs and Emacs.
This is a difficult issue, as all maintainers supporting elisp
packages have to agree on this. Furthermore there should be a passage
in the policy manuals about elisp packages.
Helmut
------------------------------------------------------------------------------
Helmut Geyer Helmut.Geyer@iwr.uni-heidelberg.de
public PGP key available : finger geyer@saturn.iwr.uni-heidelberg.de
Attachment:
pgpBsj_DCO1ne.pgp
Description: PGP signature