[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: relative load-file

From: Rocky Bernstein
Subject: Re: relative load-file
Date: Fri, 13 Nov 2009 10:03:37 -0500

On Fri, Nov 13, 2009 at 9:22 AM, Stefan Monnier <address@hidden> wrote:
> 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.

Looks like that code has been there for over a decade, since '93 in fact.  But I certainly understand your concern and I too have some trepidation. I can and will remove that condition leaving the remaining ones when it becomes a problem.
I can't think of any case
where it can give you better info than `load-file-name'.

We've gone over this - inside eval-buffer.

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

I see.  You seem to have strong and somewhat self-fulfilling views of what programmers should do or not do in Emacs.

But given that you have said don't use this style and, worse, it is in those class of things that you "discourage",  your opinion of what is likely to occur for those who do use the style has less value than if you were coming from this as and advocate or as someone who had used the style.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]