Re: Some XEmacs issues and proposals
* 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/87hdgwebu7.fsf@marant.org>
>> 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
Reply to: