Re: relative load-file

[Stefan Monnier]

> Sorry for the delay. The usual excuse(s): real life, etc ...

There's no hurry: this is a mailing-list, not an IRC channel.

> I looked again deeper at the code in* src/lread.c*, and see in fact
> *load-file-name* comes pretty close.  But better is *(car
> current-load-list)* since *current-load-list* is set from the
> C function *readevalloop()*.

current-load-list is an internal undocumented variable.
I'd stay far away from it if I were you.  I can't think of any case
where it can give you better info than `load-file-name'.

>> Then I may have misunderstood something.  Can you state those cases
>> again where
>> 
>> (load (expand-file-name <foo> (file-name-directory
>> (or load-file-name buffer-file-name))))
>> 
>> won't do the right thing and yet those cases do show up?

> One simple example characteristic of a class of things is to put
> a *(find-file ...)* right before that load and evaluate the buffer.

This example seems to fail the "those cases do show up" test.  Not just
because the requires/loads tend to occur early in an Elisp buffer, but
also because a call to `find-file' (or set-buffer for that matter) at
the top-level of an Elisp buffer is extremely rare and strongly
discouraged by the convention that loading an Elisp file should not have
any "visible effect" (this convention is useful/necessary to allow
things like Customize to load files at will, e.g. just to get the needed
info to build a customization buffer).


        Stefan