[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XEmacs, Emacs and elisp



>>>>> "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


Reply to: