Re: Problem mit symlinks, locate-library and load-history [Was: <Something else>]

[Richard Stallman <rms@gnu.org>]

    , 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:

Yes.

    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?