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: Fri, 13 Nov 2009 00:59:37 -0500 Message-ID: <6cd6de210911122159k7a0254dcgf74837e08f863db5@mail.gmail.com> References: <4AFCED98.1080209@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636d34bfe660f6304783a5def X-Trace: ger.gmane.org 1258091998 11910 80.91.229.12 (13 Nov 2009 05:59:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 05:59:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 06:59:51 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 1N8pCJ-0000Td-7Y for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 06:59:51 +0100 Original-Received: from localhost ([127.0.0.1]:33696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8pCI-0002ch-JV for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 00:59:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8pCC-0002cU-3r for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:59:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8pC7-0002bg-6B for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:59:43 -0500 Original-Received: from [199.232.76.173] (port=58736 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8pC7-0002bb-0s for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:59:39 -0500 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:32891) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8pC6-0000jU-F4 for emacs-devel@gnu.org; Fri, 13 Nov 2009 00:59:38 -0500 Original-Received: by pzk11 with SMTP id 11so1893525pzk.14 for ; Thu, 12 Nov 2009 21:59:37 -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=agHODiijBIH1pnrjI9P37Mw/slJREVEFWlpSevuBt/Y=; b=fO1XK3/Hk9/+BOaYu7LZh6Ph30ilWUCHGsE7ZnBxK9fX5kJCLssFM+yu9PDm8Zpfq7 SPUqQ5xFqUZ7cYvEstI0NglnXYA+5vMK5D1I5SjgftCEL9lvBg15eYNTORRYH/H2hBZe 80ziiRuG+uUXy2Tu+yok3VpiFU1kbNDvfCR3Q= 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=k6WZ3gkaO10udMsP+BWYXMB/8R7bybDMPU7wrYKBjukJoOsDKBPc6GRc34cI8ZsgEz ynzeF/kEBRJwQRCVk8J6ScylPRruGP/k63+jrD4M/bIODOvTJJ7gI/pMc1DccV3GHjIO 6gUhy/QI9ox300+VKahoZWvqilrPAGLilWxcs= Original-Received: by 10.142.74.19 with SMTP id w19mr432399wfa.196.1258091977248; Thu, 12 Nov 2009 21:59:37 -0800 (PST) In-Reply-To: <4AFCED98.1080209@gmx.de> X-Google-Sender-Auth: 789c93f69c015dd2 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:116928 Archived-At: --001636d34bfe660f6304783a5def Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 13, 2009 at 12:24 AM, grischka wrote: > > [...] > > That is, one wants to load an Emacs Lisp file relative the file > > > that issues the load which is often in the same directory or a > > nearby directory. > > > > This would be easy if there were a variable like __FILE__ that Ruby > > provides. > > Why would you need __FILE__ if in emacs you can type much more easily > #$ > As in > (load (concat (file-name-directory #$) "extra-stuff")) > Never ascribe to willful intent that which can be easily explained by ignorance :-) I've just read up on this, and although it is appealing and another heuristic that can be tried, it looks as though it too is sometimes gives nil in cases where say (*car current-load-list)* works, just like * load-file-name*. In fact I'd be curious to learn the differences between it and *load-file-name.* Off hand, I'd guess that #$ persists after loading -- when it is set -- whereas *load-file-name* and the *car* don't, but otherwise they are the same. Anyone know or care to comment? Here is the test I tried. I put this in a file */tmp/foo.el: *(message "++1 %s" #$) (message "++2 %s" (car current-load-list)) When I eval-buffer I get: ++1 nil ++2 /tmp/foo.el Of course if I* load-file* it, they both come out with the same file names. Thanks for the idea and info! > --- grischka > > --001636d34bfe660f6304783a5def Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 13, 2009 at 12:24 AM, grisch= ka <grishka@gmx.de> wrote:
> [...]
> That is, one wants to load an Emacs Lisp file relative the file

> that issues the load which is often in the same directory or a
> nearby directory.
>
> This would be easy if there were a variable like __FILE__ that Ruby > provides.

Why would you need __FILE__ if in emacs you can type much more easily
=A0 #$
As in
=A0 (load (concat (file-name-directory #$) "extra-stuff"))

Never ascribe to willful intent that which can be easil= y explained by ignorance :-)

I've just read up on this, and alth= ough it is appealing and another heuristic that can be tried, it looks as t= hough it too is sometimes gives nil in cases where say (car current-load= -list) works, just like load-file-name. In fact I'd be curio= us to learn the differences between it and load-file-name. Off hand,= I'd guess that #$ persists after loading -- when it is set -- whereas = load-file-name and the car don't, but otherwise they are = the same. Anyone know or care to comment?

Here is the test I tried. I put this in a file /tmp/foo.el:

<= /i>(message "++1 %= s" #$)
(= message "++2 %s" (car current-load-list))

When I eval-buffer I get:

++1 nil
++2 /tmp/foo.el

Of course if I load-file it, they both come out with the same fi= le names.

Thanks for the idea and info!



--- grischka


--001636d34bfe660f6304783a5def--