Re: Some XEmacs issues and proposals
Moin Ralf, dear list,
On 4281 September 1993, Ralf Angeli wrote:
> 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.
First of all, I should mention that I'm unaware of any discussion on
xemacs-beta, so I might not fully understand all issues. If so, please
elaborate.
> 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.
I don't consider this a problem, quite to the contrary. The observed
behaviour is in my understanding a feature. The directory
/usr/local/share/emacs/site-lisp has been traditionally been used as a
*common* directory in which to put files that are *intended* to be
shared by users. I happen to use it for about eleven years now and it
has always contained common startup-files as well as source code that
is not distributed with either Emacs.
Incompatibility concerns compiled Emacs Lisp files mainly and there
are solutions to these concerns (one: use xemacs/ and fsfmacs/
subdirectories of site-lisp/ for the *elc-files, two: don't compile).
Please also note that the problem is not really a XEmacs concern, but
a version issue in general: there have been incompatibilities in
compiled Elisp files between Emacs numbers (IIRC, 19 elcs vs. 20
elcs), and AFAIK, that's the reason for the version-numbered
subdirectories under /usr/share/emacs/.
> 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.
Come on, this is really a ridiculous example. Debian ships (at least
the last time I looked) an AUCTeX package that will not polute any
directory intended for the /local/ additions of site-administrators.
A much better example could have been a local installation of
e.g. SLIME. However, during installation I didn't encounter any
problems with XEmacs 21.5 and Emacs 21.3. Oops.
> 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.
Sure. If you happen not to know how to use a rifle, it's quite likely
you'll shoot yourself in the foot, and Emacs and XEmacs are two hells
of a machine gun. I have maintained multiple Emacs environments for
several years and there are really known ways to handle the
problem. Actually, Debian itself ships such a known way to install
it's Elisp packages.
> 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.
I wholeheartedly disaggree. This results in duplicate local start-up
code and duplicate source code storage etc., which is btw. one of the
major drawbacks of the XEmacs package system, too (maintaining common
versions of major packages between different Emacs incarnations *is* a
concern, which is silently ignored by the XEmacs package system).
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erklärt
20: Multimediaentwickler
Grafiker (Kristian Köhntopp)
Reply to: