* Holger Schauer (2005-05-30) writes: > 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.
You can find the discussion in the subthread starting with the message <URL:http://mid.gmane.org/[EMAIL PROTECTED]> >> 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. [...] > 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. If /usr/local/share/emacs/site-lisp were a directory to be used by XEmacs then why isn't it included in XEmacs' paths.h or found by (paths-find-site-lisp-directory '("/usr/local")) in case XEmacs is configured with a bare ./configure? The vanilla XEmacs 21.4 on my system which is configured like this returns /usr/local/lib/xemacs/site-lisp for the latter command. > 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). That doesn't make sense because $PREFIX/share/emacs is a hierarchy traditionally used by GNU Emacs. For example the CVS Emacs I have here puts its version dependent lisp files into /usr/local/share/emacs/22.0.50. Hence, a proper setup would mean to have the directory hierachies $PREFIX/share/xemacs for XEmacs and $PREFIX/share/emacs for GNU Emacs. If you want a hierarchy for common files you could follow J�r�me's suggestion of $PREFIX/share/emacsen. >> 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. Please read the paragraph you quoted again. I was talking about a _manual_ installation of AUCTeX, not the Debian package. >> 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). Well, nobody has commented yet on J�rm�me's suggestion. I think it could be a way out of this mess. -- Ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
