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 23:34:04 -0500 Message-ID: <6cd6de210911122034y9c3338epcf18a36a1cdf77b3@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> <6cd6de210911111321t1176868yba2f07ca48f6b186@mail.gmail.com> <6cd6de210911111701s5d5a989fp27386dd1379065ff@mail.gmail.com> <6cd6de210911111809j526ce8bfmcb5d57f907afff96@mail.gmail.com> <6cd6de210911120501u24047705w5caad5112db6cb45@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd32e2e797c7e0478392b5a X-Trace: ger.gmane.org 1258086869 2525 80.91.229.12 (13 Nov 2009 04:34:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 04:34:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 05:34:22 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 1N8nrZ-0002QD-VE for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 05:34:22 +0100 Original-Received: from localhost ([127.0.0.1]:35443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8nrZ-0007dZ-9Q for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2009 23:34:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8nrS-0007az-NN for emacs-devel@gnu.org; Thu, 12 Nov 2009 23:34:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8nrN-0007Wt-50 for emacs-devel@gnu.org; Thu, 12 Nov 2009 23:34:13 -0500 Original-Received: from [199.232.76.173] (port=35587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8nrM-0007Wq-WD for emacs-devel@gnu.org; Thu, 12 Nov 2009 23:34:09 -0500 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:60081) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8nrM-0002LE-GY for emacs-devel@gnu.org; Thu, 12 Nov 2009 23:34:08 -0500 Original-Received: by pzk11 with SMTP id 11so1857748pzk.14 for ; Thu, 12 Nov 2009 20:34:04 -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=iOIFmrBnhevrIOcAOYxAmma6BB5zAvhW0P0aQlTn1uE=; b=bGCwFhj8gngA2CEcykqysOV3QG/bKV9pmOD18dVmXEYftafxz79bPcUqHDMJiiwluu n/GvkOr3ggmOIoX+RUp9Zm0D0tNkYrXfuVw1MP+TSMYLFnv/MX52RlVc8wVT1g9cnPQb xc6wp4Oofhex1eNZlJvvu91mWsNAvWh5pooQo= 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=u794LR33bbDLtgLnxGEKaptrrb5JQTyiQ0yLE5lW0kymONbRms4ov1kH5DrjhK4N0e yrd2IUwdrKSnf+lnqRdWjGG39MHXNbaiKOVz4y2CZMpJBIqpQlFHqpqIi5cjX9wVTKUo RxPPuNmGMQM2XLByv8wtaOpUBDhAhqsAdN6lA= Original-Received: by 10.142.209.20 with SMTP id h20mr421220wfg.167.1258086844693; Thu, 12 Nov 2009 20:34:04 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 837dfd53be223bf1 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:116921 Archived-At: --000e0cd32e2e797c7e0478392b5a Content-Type: text/plain; charset=ISO-8859-1 Sorry for the delay. The usual excuse(s): real life, etc ... On Thu, Nov 12, 2009 at 10:34 AM, Stefan Monnier wrote: > > 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. > > I have no idea what simple change you're talking about. > 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()*. Since *readevalloop* is used from both *load*-like calls and *eval*-like calls, it covers both kinds of ways to run code. More important, in the *eval*-like calls, the value isn't changed by evaluating buffer-changing operations as is the case with*(buffer-file-name) *. But since this is low-level and not a public API, I'll do a *stringp* test and if that fails try the other hueristics. > >> > 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. > > Then I may have misunderstood something. Can you state those cases > again where > > (load (expand-file-name (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. However since the intent is to replace *require* (and *load*), the intended uses are somewhat stereotypical. So commonly such statements get run early close to the beginning of the invocation of code. I can add a suggestion/warning to this effect.** --000e0cd32e2e797c7e0478392b5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for the delay. The usual excuse(s): real life, etc ...

On Thu, Nov 12, 2009 at 10:34 AM, Stefan Monnier <monnier@iro.umo= ntreal.ca> wrote:
> It is becoming clear now that this is something that can be addressed=
> pretty easily by making a small change to the Emacs source. =A0However= ,
> failing that, the mechanisms for simulating this are a little arcane.<= br>
I have no idea what simple change you're talking about.

I looked again deeper at the code in src/lread.c, an= d see in fact load-file-name comes pretty close.

But better i= s (car current-load-list) since current-load-list is set from= the C function readevalloop(). Since readevalloop is used fr= om both load-like calls and eval-like calls, it covers both k= inds of ways to run code. More important, in the eval-like calls, th= e value isn't changed by evaluating buffer-changing operations as is th= e case with (buffer-file-name).

But since this is low-level and not a public API, I'll do a stri= ngp test and if that fails try the other hueristics.


=

>> > First, none of the examples I have given do I find really cor= ner 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.

Then I may have misunderstood something. =A0Can you state those cases=
again where

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

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=A0 a (find-file ...) right before that load and evaluate the = buffer.

However since the intent is to replace require (and load)= , the intended uses are somewhat stereotypical. So commonly such statements= get run early close to the beginning of the invocation of code. I can add = a suggestion/warning to this effect.
--000e0cd32e2e797c7e0478392b5a--