From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Re: relative load-file Date: Thu, 12 Nov 2009 08:01:36 -0500 Message-ID: <6cd6de210911120501u24047705w5caad5112db6cb45@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> <87ljic7vu9.fsf@thinkpad.tsdh.de> <6cd6de210911111126y62c7dfceqb82092c9eef9890d@mail.gmail.com> <6cd6de210911111321t1176868yba2f07ca48f6b186@mail.gmail.com> <6cd6de210911111701s5d5a989fp27386dd1379065ff@mail.gmail.com> <6cd6de210911111809j526ce8bfmcb5d57f907afff96@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00504502b738ae937404782c2490 X-Trace: ger.gmane.org 1258031212 27821 80.91.229.12 (12 Nov 2009 13:06:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2009 13:06:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 14:06:45 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N8ZNp-0007Dl-AC for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2009 14:06:43 +0100 Original-Received: from localhost ([127.0.0.1]:52656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8ZNo-0000Q5-1W for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2009 08:06:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8ZJ1-0007E6-CY for emacs-devel@gnu.org; Thu, 12 Nov 2009 08:01:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8ZIw-0007Ca-4a for emacs-devel@gnu.org; Thu, 12 Nov 2009 08:01:42 -0500 Original-Received: from [199.232.76.173] (port=50007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8ZIv-0007CO-SG for emacs-devel@gnu.org; Thu, 12 Nov 2009 08:01:37 -0500 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:53589) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8ZIv-0002cq-6V for emacs-devel@gnu.org; Thu, 12 Nov 2009 08:01:37 -0500 Original-Received: by pzk11 with SMTP id 11so1397366pzk.14 for ; Thu, 12 Nov 2009 05:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=MQsuJkRnKAhvVWCH0ZoN+jNWGh7QPqddJqwZmJRHRZw=; b=mVyiqQbNXs+VlfU6RlMHGBeYs6yiyBz5iD5AMXx+pArLFNo7aHqBFlgJYDFT5CGWl7 nBHY9z8ymIKa+/5Hrwv3zjGxCrBIx6M7sYAJuM+Bh3zdBxctLevrG3JZqRDR4BuoTK+P /DVTwkVUkIYNWgd4IeDo0dlQ6DG9jCU4DGlwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oIhR15MM0E8AS7nRRWzu/Cz3GC0H4flE4FkKNCeVmOz8DZpfgDeQMA3M4O8QVaJbzN li7yTIrVMKRrQ7Uk6sqdeMRMqqdJtAMmmdMlKm0wH9obYxhLBFEVkAJ0ewjPWWYTbT8y mWQUOhpyAvQdky/5HI+fajqW6L3BD8QFZ1QnA= Original-Received: by 10.142.9.34 with SMTP id 34mr317921wfi.114.1258030896157; Thu, 12 Nov 2009 05:01:36 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 2be5296ad7815038 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116879 Archived-At: --00504502b738ae937404782c2490 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 11, 2009 at 11:22 PM, Stefan Monnier 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 (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 > --00504502b738ae937404782c2490 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 sour= ce code, I
> *wouldn't* be asking.

Here it is then:

=A0(load (expand-file-name <foo> (file-name-directory
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (or load-f= ile-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. =A0It's simply not possi= ble 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 "loa= d" because code can get loaded into Emacs outside of loading a file. <= br> =A0
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 easi= ly 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 fi= nd files relative to its own location! Perhaps part of the reason this feat= ure was provided is because it was felt that it too many programmers were u= sing those heuristics to create really ugly and unreliable code; yet it cou= ld be done pretty simply and reliably from the interpreter.

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

Since we are into analo= gies, here's how I think of this.

Suppose I have a programming l= anguage that doesn't have a debugger because the run-time support for it is lacking. I suppose then that could s= ay that asking for debugging=A0 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 load= ing and so on reduce or I suppose some would say eliminate the need. So sur= e, one could argue that the deficiency is in how the programmer programs, n= ot the system.

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

> 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 f= act 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. =A0The main reason i= s
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 kin= d 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-m= ill
> users need not have to be concerned - they can use the feature and hav= e
> 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 a= re 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!
=A0


=A0 =A0 =A0 =A0Stefan

--00504502b738ae937404782c2490--