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: Wed, 11 Nov 2009 21:09:58 -0500 Message-ID: <6cd6de210911111809j526ce8bfmcb5d57f907afff96@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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636b2be3645e4b80478230a93 X-Trace: ger.gmane.org 1257991819 25110 80.91.229.12 (12 Nov 2009 02:10:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2009 02:10:19 +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 03:10:13 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 1N8P8W-00078D-5U for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2009 03:10:12 +0100 Original-Received: from localhost ([127.0.0.1]:33187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8P8V-0005BO-L3 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 21:10:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8P8N-00056w-Ig for emacs-devel@gnu.org; Wed, 11 Nov 2009 21:10:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8P8J-00052w-VB for emacs-devel@gnu.org; Wed, 11 Nov 2009 21:10:03 -0500 Original-Received: from [199.232.76.173] (port=41362 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8P8J-00052n-Ou for emacs-devel@gnu.org; Wed, 11 Nov 2009 21:09:59 -0500 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:51797) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8P8J-0006tG-9r for emacs-devel@gnu.org; Wed, 11 Nov 2009 21:09:59 -0500 Original-Received: by pzk11 with SMTP id 11so1112548pzk.14 for ; Wed, 11 Nov 2009 18:09:58 -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=A7x6rhmG21Kp35dG9cvCF/S/bUaOUC2FRsUhMGl9e0A=; b=Wqb3l9ijZN+tVUtSLBZWz3/G7UkzpW+HbAb6S4DT7XQ2bjfnMd/8u/pJxh5RPygx8F C3gQ6nntUC8KUzaiuyOIIid0nXdZHcJedyFb2pNgmz2Geiue3IPqkZq9E6YN/4WbDelN OCk+yIwyI8rajHQ8RNGgVOUC5U9sjBbzI25ys= 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=jTs1lY1q+3easgE3cpHu36v08GfovyTF9U3PuV+B8nGPw8flbFQPNsC5I5QlhaA2kj u+eBF7xZor6AkDo/2JVBjIczelWvz4rHE2x+phKvs6Y+/jA8biB8TZ4gNk+Qo17lH7Qn FvpdWnD8EPjBYd35xUBBtHrGDEGP3Q7i1x2SA= Original-Received: by 10.142.55.8 with SMTP id d8mr261882wfa.54.1257991798383; Wed, 11 Nov 2009 18:09:58 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 923f08691229fa90 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:116856 Archived-At: --001636b2be3645e4b80478230a93 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 11, 2009 at 8:20 PM, Stefan Monnier wrote: > > When load-file-name is nil, this uses the name of default directory of > > current buffer. But that's not the same as the directory of the file > > containing the load-relative function. > > > For example, I could have eval'd a buffer that did a load-relative of a > file > > in a different directory. Even without this, I can change the default > > directory using the cd function. And changing the default directory never > > changes the file location of the file issuing load-relative. > > > Any other thoughts? > > You obviously know enough about the problem to "fix it" further > Huh? If I knew a good solution to this short of changing the source code, I *wouldn't* be asking. (e.g. using buffer-file-name if you prefer it to default-directory). > 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. I just took a look at the src/lread.c and although it is a somewhat bit mysterious to me, from what I gather from readevalloop (and I could be *very very* wrong here) is that when a file is read in, perhaps there *is no*buffer created in the Emacs sense. Avoiding buffer creation to read in a Lisp file make sense because one wants reading Lisp code to be fast; furthemore there is no reason to store the entire source contents as source contents after the file is read/eval'd. (The vast majority of compilers don't save the source text). I don't see any point in fixing it further, since there will always be > corner cases where it doesn't do what the user intended. > A couple of things strike me as weird. First, none of the examples I have given do I find really corner case. 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.) 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. Thanks for the help. > > Stefan > --001636b2be3645e4b80478230a93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2009 at 8:20 PM, Stefan = Monnier <m= onnier@iro.umontreal.ca> wrote:
> When load-file-name is nil, =A0this uses the name of= default directory of
> current buffer. But that's not the same as the directory of the fi= le
> containing the load-relative function.

> For example, I could have eval'd a buffer that did a load-relative= of a file
> in a different directory. Even without this, I can change the default<= br> > directory using the cd function. And changing the default directory ne= ver
> changes the file location of the file issuing load-relative.

> Any other thoughts?

You obviously know enough about the problem to "fix it" fur= ther

Huh? If I knew a good solution to this short = of changing the source code, I wouldn't be asking.

(e.g. using buffer-file-name if you prefer it to default-directory).

What strikes me wrong about going in the direction of us= ing buffer-file-name or using buffers is that that we are introspecting abo= ut is the running code.

I just took a look at the src/lread.c and although it is a somewhat bit= mysterious to me, from what I gather from readevalloop (and I could be = very very wrong here) is that when a file is read in, perhaps there = is no buffer created in the Emacs sense.

Avoiding buffer creation to read in a Lisp file make sense because one = wants reading Lisp code to be fast; furthemore there is no reason to store = the entire source contents as source contents after the file is read/eval&#= 39;d. (The vast majority of compilers don't save the source text).

I don't see any point in fixing it further, since there will always be<= br> corner cases where it doesn't do what the user intended.

A couple of things strike me as weird.

First, none of th= e examples I have given do I find really=A0 corner case.=A0 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.)

Second, a reason one might try to encapsulate this in a library is to b= e 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 co= nfidence that it does the right thing.

Thanks for the help.



=A0 =A0 =A0 =A0Stefan

--001636b2be3645e4b80478230a93--