Re: relative load-file

[Rocky Bernstein <rocky@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4170 bytes --]

On Wed, Nov 11, 2009 at 11:22 PM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:

> > Huh? If I knew a good solution to this short of changing the source code,
> I
> > *wouldn't* be asking.
>
> Here it is then:
>
>  (load (expand-file-name <foo> (file-name-directory
>                                 (or load-file-name buffer-file-name))))
>
> > What strikes me wrong about going in the direction of using
> > buffer-file-name or using buffers is that that we are introspecting
> > about is the running code.
>
> You can't make it work in all cases.  It's simply not possible because
> code exists outside of any notion of file, so "relative file name"
> cannot always make sense.
>

This is a silly argument. It is neither necessary nor desirable to make
load-relative work in cases where it makes no sense. Surely one wouldn't
suggest banning "load" because code can get loaded into Emacs outside of
loading a file.


> So what strikes you as wrong is really a fundamental problem in what
> you're requesting, rather than a problem in the solutions I proposed.
>

Obviously, you think of it that way.

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.



> It's similar in a sense to the issue of a binary executable trying to
> find associated files relative to its own location: in general the
> executable cannot know its own location, so the best you can do is use
> heuristics like look at $0 and search it in $PATH.
>

But there are systems like Scala and Ruby where the running program can find
files relative to its own location! Perhaps part of the reason this feature
was provided is because it was felt that it too many programmers were using
those heuristics to create really ugly and unreliable code; yet it could be
done pretty simply and reliably from the interpreter.

Around the time that Emacs is in readevalloop, it knows very well the file
name that it is working with.

Since we are into analogies, here's how I think of this.

Suppose I have a programming language that doesn't have a debugger because
the run-time support for it is lacking. I suppose then that could say that
asking for debugging  in such a programming language is a fundamental
problem in the request. Verily there are many folks who live without
debuggers. Techniques like test-driven development, modular programming,
proving your program correct, interactive shells, dynamic loading and so on
reduce or I suppose some would say eliminate the need. So sure, one could
argue that the deficiency is in how the programmer programs, not the system.


By the way, in such systems it is sometimes possible to cull together
something that sort of feels like a debugger and so that sometimes happens.


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


> > These and many more have come up. (Recall that I have been using this
> mode
> > of working, and I gather from prior remarks you haven't.)
>
> This mode of working is not encouraged in Emacs.  The main reason is
> probably just historical accident, but the fact that it can't work
> reliably in all cases would be a good reason to retroactively justify
> that choice.
>

Yes, I am very familiar with this kind of good reason. :-)


> > Second, a reason one might try to encapsulate this in a library is to be
> > able to handle as many of the corner cases as possible so run-of-the-mill
> > users need not have to be concerned - they can use the feature and have
> > confidence that it does the right thing.
>
> That would make sense if the functionality was important, but I haven't
> seen evidence that it is.
>

And I'm sorry, but I'm not going to try to convince you.

As I wrote before, folks are happy with the status quo, or at least not too
unhappy with it. So again, thanks for the help. I have a clearer idea of
where things stand now.

Keep up the good work!


>
>
>        Stefan
>

[-- Attachment #2: Type: text/html, Size: 5857 bytes --]