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

On Thu, Nov 12, 2009 at 10:34 AM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:

> > It is becoming clear now that this is something that can be addressed
> > pretty easily by making a small change to the Emacs source.  However,
> > failing that, the mechanisms for simulating this are a little arcane.
>
> I have no idea what simple change you're talking about.
>

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()*. Since *readevalloop* is used from both
*load*-like calls and *eval*-like calls, it covers both kinds of ways to run
code. More important, in the *eval*-like calls, the value isn't changed by
evaluating buffer-changing operations as is the case with*(buffer-file-name)
*.

But since this is low-level and not a public API, I'll do a *stringp* test
and if that fails try the other hueristics.



> >> > First, none of the examples I have given do I find really corner case.
> >> They work fine with the above code.
> > Um, no. I cited two kinds of situations that fail with the above code and
> > both in fact do come up.
>
> 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.

However since the intent is to replace *require* (and *load*), the intended
uses are somewhat stereotypical. So commonly such statements get run early
close to the beginning of the invocation of code. I can add a
suggestion/warning to this effect.**