Re: Problem mit symlinks, locate-library and load-history

[Alan Mackenzie <acm@muc.de>]

Hi, Richard!

[ .... ]

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

After playing around a bit with C-h v and load-file, the top element of
my load-history has this file name:

    "/home/acm/emacs/emacs/lisp/loadhist.elc"

This is inconsistent with the entry for a preloaded lisp file:

    "/mnt/hda7/emacs/lisp/font-lock.el"

[Note:  these files are in the same directory, "/home/acm/emacs" being a
symbolic link pointing at "/mnt/hda7".]

This inconsistency is surely a bug.  The prime cause of this is, IMAO,
the doc string of load-history - it fails to state whether "file.elc" or
"file.el" should be recorded, and also fails to state that a truename,
rather than a name with a symbolic link, is recorded - thus people using
load-history have become confused.

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

Ah.  OK.

>    On the other hand, if absolute pathnames are to be used, shouldn't
>    they first be filtered with file-truename, like this:

>Yes.

#########################################################################
There's another bug in eval-after-load:

Suppose that ..../emacs/lisp/foobar.el exists, but not foobar.elc.

In Emacs 22:
M-x load-file <ret> ..../emacs/lisp/foobar.el
M-x byte-compile-file <ret> ..../emacs/lisp/foobar.el
M-: (eval-after-load "foobar" '(<something>))

The eval-after-load form should trigger immediately.  It doesn't, though,
because locate-library finds "..../emacs/lisp/foobar.elc", but
load-history (correctly) contains "..../emacs/lisp/foobar.el".

Shouldn't eval-after-load strip the ".elc", then loop through
load-suffixes?  (BTW, top marks to the person who decided not to call
this variable "load-suffices".  ;-)

#########################################################################
How about this as a resolution of the problem:

(i) load-history should record the absolute file-truename of the file which
was actually loaded, whether that be ".../directory/file.el",
".../directory/file.elc" or even ".../directory/file".  The files loaded at
dump-time would thus be recorded as .elc, not .el as at present.

(ii) locate-library and friends should remain as they are, returning the
path as recorded in load-list, even if this might contain symbolic links.

(iii) eval-after-load, and suchlike: they should work like my proposed
function loaded-filename (see below).

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

cus-edit.el L2159
info-xref.el L286
subr.el L1381 (that's eval-after-load)

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

How about this?

    (defun loaded-filename (filename &optional exact-suffix)
      "Get the absolute file name from which Elisp file FILENAME was loaded.
    Return nil if the file isn't found.  The returned file name will be a
    true name \(i.e. without symbolic links).

    FILENAME is a string.  It may be an absolute file name like
    \"/usr/local/bin/emacs/lisp/foobar\", or a bare file name like
    \"foobar\" or \"foobar.el\".  In the latter case, it will be found only
    if it is in a directory in `load-list'.

    If EXACT-SUFFIX is non-nil, the function searches only for FILENAME.
    Otherwise it also searches for the file names formed by replacing
    FILENAME's suffix, if any, by each of the suffixes in `load-suffixes'.
    ............)

>Would someone like to do that, and ack?

This email is NOT such an ACK.  ;-)

-- 
Alan Mackenzie.