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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
