Some XEmacs issues and proposals
Hi everybody,
following up on a discussion from the xemacs-beta mailing list I'd
like to point out some issues with the XEmacs package Debian is
providing and suggest possible remedies. The problems are affecting
AUCTeX to some extent, so I will refer to it as an example when
appropriate.
1) /usr/local/share/emacs/site-lisp in load-path (bug #309747)
The load-path of Debian's XEmacs includes the directory
/usr/local/share/emacs/site-lisp. This directory is traditionally
used for the manual site-wide installation of GNU Emacs add-ons.
Basically the same is true for /usr/share/emacs/site-lisp. That means
one could question the decision adding this directory to load-path as
well.
Both directories are mentioned in Debian's Emacs policy document as
being a minimum requirement for all Emacsen. While one could argue
that /usr/share/emacs/site-lisp is under the control of the package
system which will assure that no files incompatible with XEmacs are
put into this directory, this is not the case for
/usr/local/share/emacs/site-lisp. One cannot rely upon local site
administrators adhering to the Debian scheme.
Taking AUCTeX as an example this means that a manual installation of
it for GNU Emacs will be put a tex-site.el into
/usr/local/share/emacs/site-lisp. The file will try to add the
content of the auctex subdirectory, i.e. both source Elisp files and
files compiled for GNU Emacs to load-path. Because
/usr/local/share/emacs/site-lisp is in XEmacs' load-path it will pick
up the AUCTeX installation intended for GNU Emacs.
Interestingly there is a peculiarity in
/etc/xemacs21/site-start.d/00debian.el which be sheer luck prevents at
least the files in the auctex subdirectory from being seen by XEmacs.
That's the setting of the variable `TeX-lisp-directory'. (I can
explain in detail what happens if somebody is interested.) This was
added nearly five years ago and is not necessary anymore because the
current XEmacs AUCTeX package does not exhibit the bug anymore for
which the variable was set in 00debian.el.
Anyway, XEmacs still picks up at least one wrong file. So taking
aside /usr/share/emacs/site-lisp because it is under the package
system's control, I think at least /usr/local/share/emacs/site-lisp
should not be added to XEmacs' load-path in order to prevent these
problems. In addition the setting of `TeX-lisp-directory' in
00debian.el should be removed.
2) xemacs-packages before site-packages (bug #151900)
Debian's XEmacs is configured to search the
/usr/share/xemacs21/xemacs-packages directory before the
/usr/share/xemacs21/site-packages directory. This is contradictory to
the search order described in XEmacs' Lispref manual:
,----[ 3.1 The User View ]
| Second, the hierarchies below each root are searched in the order
| `site-packages', `infodock-packages', `mule-packages', then
| `xemacs-packages'.
`----
That means in case you want to do a site-wide installation of an
add-on package for XEmacs, which will be put into the site-packages
directory, it will be shadowed by the installation in the
xemacs-packages directory until the latter is removed manually. This
is not the proper behavior.
So my proposal would be to change the order of package directories
as described in the Lispref manual.
3) Info documentation
Some of XEmacs' documentation is not accessible from inside of
Debian's XEmacs. For example `C-h C-c save-buffer RET' or similar
does not work. Unfortunately I am not familiar with how an
appropriate layout of info files and directories should look like or
what was changed in Debian which broke commands like the one above, so
I cannot make a suggestion here.
--
Ralf
Reply to: