>>>>> "HG" == Helmut Geyer <Helmut.Geyer@IWR.Uni-Heidelberg.De> writes:
HG: 1) The main problem is that XEmacs (19.14) cannot read Emacs
HG: (19.34) byte-compiled lisp files, while Emacs can in fact read
HG: XEmacs compiled .elc files. If you want to have a directory
HG: containing lisp files for both of them (it certainly is
HG: possible to support both variants in a single lisp file), you
HG: have to ensure that only XEmacs is used for byte-compiling.
What is the exact difference between Emacs & XEmacs byte-code? If
Emacs byte-code is faster or has any other advantage (why they changed
it?), I don't agree with this solution.
HG: This could be ensured by using a shell script, say
HG: emacs-byte-compile that will use XEmacs if installed and Emacs
HG: otherwise). Every package that uses byte-compiling must use
HG: this shell script.
No. Different packages can have different methods of distinguishing
between Emacs and XEmacs for compilation (like EMACS variable, editing
Makefile, etc.). How would you cover all of them by single shell
script?
I think everyone can check `[ -f /usr/bin/xemacs ]' which is simple
and portable. I can see no need for special shell script.
HG: 2) there are several packages that are neither part of Emacs
HG: nor of XEmacs. Currently those packages are only available for
HG: Emacs, not for XEmacs (e.g. auctex or tm). To use them with
HG: XEmacs you need to hack the packages, although both packages
HG: support both variants of GNU Emacs. There are basically two
HG: ways to handle this: a) make two debian packages, each
HG: supporting a single variant of GNU Emacs. Advantage: simple,
HG: easy to maintain. Disadvantage: cluttering up of package
HG: namespace and unnecessary use of disk space.
HG: b) use a single debian package to
HG: support both Emacsen using a special directory added to the
HG: load path of both (e.g. /usr/share/emacs/packages). The
HG: package has to be compiled either at installation time (using
No installation time compilation please! It's slow and possibly
fragile.
HG: the script mentioned above) or has to be built using
HG: XEmacs. The later method has the disadvantage that every
HG: package maintainer building a package including byte-compiled
HG: must have XEmacs installed.
Especially until XEmacs stops to conflict with Emacs. :-)
HG: Advantage: no namespace or disk space cluttering.
HG: Disadvantage: use of a non-standard element in both load paths,
HG: more complicated for package maintainers.
HG: 3) There is a lot of functionality in elisp packages that is
HG: included in some add-ons for emacs while being part of the
HG: main xemacs distribution. This should not be needed as it is
HG: possible (at least for some packages) to be used by both
HG: XEmacs and Emacs. An example for this is vm. As XEmacs 19.15
HG: will come in an unbundled form as well as the current kitchen
HG: sink distribution, this problem will be basically the same as
HG: the one above. So I propose to leave this problem alone until
HG: XEmacs 19.15 is released.
HG: 4) single elisp files or packages that are not to be compiled
HG: definitely should be in the load path of both Emacsen. This
HG: includes e.g. debian-changelog-mode.el. If there are problems
HG: with compatibility on the elisp level, they should be fixed on
HG: that level. (elisp is perfectly capable of distinguishing
HG: between Emacs versions and variants). So I will go even
HG: further than simply including /usr/lib/emacs/site-lisp in the
HG: load path of XEmacs by proposing there should be a single
HG: site-lisp directory used for both Emacs variants. Once debian
HG: changes from using FSSTND to the (hopefully soon released) FHS
HG: it will be clear where this directory is to be:
HG: /usr/share/emacs/site-lisp. Until then I suggest using the
HG: Emacs location /usr/emacs/site-lisp for both XEmacs and Emacs.
I think we should have three directories, something like `emacs',
`xemacs', and `emacsen' (or whatever we name them). One for Emacs
elc files, one for XEmacs one, and one for shared.
It should be leaved on each package maintainer's responsibility
whether he makes a single package for both Emacsen (which should be
prefered) or decides to make two packages (which may be almost
necessary sometimes) or makes only one package for one Emacs (which
may be absolutely necessary sometimes).
HG: This is a difficult issue, as all maintainers supporting elisp
HG: packages have to agree on this. Furthermore there should be a
HG: passage in the policy manuals about elisp packages.
I agree.
I think these problems shouldn't be fatal for avoiding of conflict
between `emacs*' and `xemacs*' packages. I hope that will be removed
until 1.3. Problems of packages can be solved later.
[But *should* be solved. One thing I don't like on Debian is that we
discuss some theme and then forget it for a long time and then discuss
it again (already discussed things, not much new) and forget it, etc
-- see shadow passwords. I think once we start to discuss some
problem we should solve it to final solution if possible.]
Milan Zamazal
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com