[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem mit symlinks, locate-library and load-history [Was: <Somethi
Re: Problem mit symlinks, locate-library and load-history [Was: <Something else>]
Mon, 20 Mar 2006 20:02:19 -0500
, and fails. There are two distinct problems here:
(i) locate-library gives a .elc, but there's a .el in load-history.
I guess eval-after-load needs to convert .elc to .el.
(ii) /home/acm/emacs is actually a symbolic link pointing at /mnt/hda7.
I guess eval-after-load needs to call file-chase-links on one or both
of the names.
(i) The dumped lisp files are byte compiled, so it seems strange indeed
that font-lock.el is record in load-history rather than font-lock.elc.
Is this a bug?
The load history is designed to refer to the source files,
and therefore treats a byte compiled file as if it were the source file.
(ii) Why on earth is eval-after-load converting "font-lock" to a full
filename and then searching for that? Surely it is sufficient that any
old font-lock has been loaded at some time (e.g., at dump time)?
Not necessarily. There can be multiple files called font-lock.el in
different directories. We would not want to have such a coincidence
in Emacs itself, but nothing stops users from having them.
On the other hand, if absolute pathnames are to be used, shouldn't they
first be filtered with file-truename, like this:
There are approximately 45 places in ..../lisp where locate-library is
used, and approximately none of them use file-truename. 3 of these are
assoc'king the result with load-history.
Which three are they? Where are they? It sounds like they may all
have a bug. It could be useful to define a subroutine to do
(assoc (file-truename (locate-library file)) load-history)))
except do it correctly.
Would someone like to do that, and ack?