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: Manoj Srivastava
Subject: Re: Debian's idiosyncratic complexification of Emacs
Date: Wed, 16 Jul 2008 09:22:10 -0500
User-agent: Microsoft Gnus Express, Build 5.13 (5.13)

On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <address@hidden> said: 

> 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.

        Which directory is that?

> And of course, any package installation that thinks it might work by
> placing .elc in the same place as .el is naive.

        Assuming you are not just trying to pick a fight, the problem
 that needs to be solved is this:

        Any add-on packages that can be byte compiled for multiple
 versions of emacs (even versions not available when the package was
 created) do not know what versions are actually installed on the users
 machine. More than one version might be installed, and flavours of
 emacs might be removed, and other ones installed later on, and the
 elisp package must keep working for the end user, seamlessly.

        So, the elisp packages only ship .el files, and on the end users
 machine, looking at the emacs versions installed, the .el files are
 byte compiled, and kept in a different directory for each version of
 emacs found.

        When a flavour of emacs is installed, it finds all third party
 elisp package on the machine, and byte compiles them, and these byte
 compiled files are removed when that flavour of emacs is removed from
 the machine.

        Now, I think it is a fine idea to hard-link the .el files into
 all these separate emacs flavour directories, and perhaps the policy
 can be evolved to specify that, so you always find the .el files  in
 the same directory as the .elc files.

> And Emacs has a command byte-recompile-directory just by mistake.

        Emacs makes no attempt to cater to the issues facing third party
 elisp packages, so someone has to pick up where emacs developers stop.
 I have emacs 21, emacs 22, emacs-snapshot, and the latest XEmacs on
 this machine, and I also keep a non-debian git checkout emacs in
 /usr/local, and I have VM working flawlessly for all these flavours.

        If you have a better idea on how this should be done, please, I
 am all ears. Snarky remarks really do not help.

        manoj
-- 
broad-mindedness, n: The result of flattening high-mindedness out.
Manoj Srivastava <address@hidden> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C





reply via email to

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