Re: Clarification of eval-after-load [was: Problem mit symlinks, locate-library and load-history]

[Alan Mackenzie <acm@muc.de>]

Evening, Stuart!

On Thu, 11 May 2006, Stuart D. Herring wrote:

>> The use of symbols (as opposed to file names) here has only just been
>> introduced into Emacs (sometime in Emacs 22), so there are many millions
>> of (eval-after-load "foo" ....) forms in existing source throughout the
>> Emacs universe.  We need to stay compatible with that source.

>Yes, I realize that.  I was just being dumb and talking before reading;
>I see now that exactly what I was suggesting is already implemented in
>parallel with the filename system.

>It seems to me that the simple way to handle the real problem (rather
>than the one I fabricated) is to fully-canonicalize (find real file
>name, find absolute file name, chase symlinks) the arguments to both
>`eval-after-load' and `load' and compare them (that is, use them to
>read/write the alist) afterwards.

I proposed a patch (for load) to do this yesterday.

>But could there be a problem where preloaded files didn't match on a
>different machine?  If so, it might make sense to express the file names
>relative to the entry of `load-path' that let them be found.

This is, in fact done.  The preloaded files are expressed relative to
..../emacs/lisp, and fleshed out to absolute names when Emacs is started.
After all, the preloaded files are loaded from the building lisp
directory, which is rarely the same as the one Emacs is installed to.

>Of course, then you couldn't chase symlinks.  Maybe during preloading
>`load-history' should get the short names (e.g., "font-lock", "simple")
>of loaded files, and then at real startup do the canonicalization before
>loading anything that would need to use `eval-after-load'?

Have a look at command-line (in startup.el) and Fload (in lread.c).  They
work almost exactly like you suggest they should.  :-)

>Since it'd only be preloaded files, customizations to `load-path' would
>probably be irrelevant, so it would be okay to resolve them before
>loading .emacs.

Indeed.

>Apologies if this is uneducated rambling; I'm not too familiar with this
>feature.

Not at all, great minds think alike.  :-)  Happy hacking!

>Davis

-- 
Alan.