emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian's idiosyncratic complexification of Emacs


From: David Kastrup
Subject: Re: Debian's idiosyncratic complexification of Emacs
Date: Tue, 15 Jul 2008 08:50:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * Stephen J. Turnbull (2008-07-15) writes:
>
>> Except for bug reports.  Debian's XEmacs (unlike, say, Mandrivel's) is
>> quite clean of core patches, so I don't recall ever needing to fire up
>> a Debian XEmacs to diagnose a bug.  (Of course, if it looks like a
>> load-path issue, I always try to bounce it back to Debian, since it's
>> their load-path, not ours.
>
> Just as an example, the Debian Emacs policy requires all Emacsen to
> have /usr/local/share/emacs/site-lisp in `load-path', even XEmacs.
> (See also <URL:http://thread.gmane.org/d6qmdp$uor$1%40sea.gmane.org>.)
> Like that XEmacs will pick up files byte-compiled for Emacs.  This
> looks pretty broken to me.

No, you don't understand: byte-compiled files should not go into
/usr/local/share/emacs/site-lisp.  This directory is only incidentally
named like a standard Emacs search path directory.  The byte-compiled
files are to be in another directory so that list-load-path-shadows has
something to think about.  And of course, any package installation that
thinks it might work by placing .elc in the same place as .el is naive.
And Emacs has a command byte-recompile-directory just by mistake.

And so on.  Really, the Debian policy is not broken.  It is just that
no-one, including Emacs and XEmacs itself, does not really appreciate
it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]