On Wed, Nov 11, 2009 at 11:22 PM, Stefan Monnier
<address@hidden> 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