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 16:21:04 -0500 Message-ID: <6cd6de210911111321t1176868yba2f07ca48f6b186@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> <87ljic7vu9.fsf@thinkpad.tsdh.de> <6cd6de210911111126y62c7dfceqb82092c9eef9890d@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636c932161f495504781f01bd X-Trace: ger.gmane.org 1257974560 9948 80.91.229.12 (11 Nov 2009 21:22:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2009 21:22:40 +0000 (UTC) Cc: Tassilo Horn , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 22:22:32 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 1N8Ke8-0004Cp-5t for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 22:22:32 +0100 Original-Received: from localhost ([127.0.0.1]:37807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8Ke7-0005Tx-IK for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 16:22:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8Kcs-0004iv-O5 for emacs-devel@gnu.org; Wed, 11 Nov 2009 16:21:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8Kcn-0004bx-TQ for emacs-devel@gnu.org; Wed, 11 Nov 2009 16:21:13 -0500 Original-Received: from [199.232.76.173] (port=52438 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8Kcn-0004bg-EC for emacs-devel@gnu.org; Wed, 11 Nov 2009 16:21:09 -0500 Original-Received: from mail-vw0-f176.google.com ([209.85.212.176]:57117) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8Kcn-0006Nj-1M for emacs-devel@gnu.org; Wed, 11 Nov 2009 16:21:09 -0500 Original-Received: by vws6 with SMTP id 6so463683vws.14 for ; Wed, 11 Nov 2009 13:21:08 -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=X0R2MrKRROrZe6kXFJk7lrQ+fruTSLxnJoIBbpXz3nE=; b=QGA4CGZrLzZroH8OszKf8DrBIvqqOj4YQVE/BJm30XVtl7Dh1eesljmE1E34TmSgrp VNQq/eGU1LWMtfB2XhQFqwcjwG631TJzE0w0vc7BtHbBBL43EWPtAvIK7lJ5VTTtlyeI +vwGz1yVFsZ7QNtGleJzR5Q3pUXQMs3H+uWKs= 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=e447VPbHDa5Og3y5b6nI1vagT0wEP33weDiCviGdrz38wa3D23Ml2mwuprBaX4xIn4 uJQ4WDk2KnUalVDeMOqX86kAY0ahUuAmG4fKdBnnXFJ9xx7HnHKqx9UEQXo9Up45cPbN q0UeUwjTDBGi56PX/WlubTkOzaU9nflKpOKiA= Original-Received: by 10.220.126.150 with SMTP id c22mr2498353vcs.66.1257974464989; Wed, 11 Nov 2009 13:21:04 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 4706f5504ecb22db 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:116845 Archived-At: --001636c932161f495504781f01bd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 11, 2009 at 3:17 PM, Stefan Monnier wrote: > > This is loading relative to the directory I started at, /tmp/proj/subdir, > > not relative to the directory that of the file that issued the load, > > /tmp/proj/test1.el. > > You can do > > (load (expand-file-name (file-name-directory > load-file-name))) > Unfortunately this doesn't work either because load-file-name might sometimes be nil. For example where in test1.el I had: (load-file "test3.el") Using the above suggestion, if you change that to (load (expand-file-name "test3.el" (file-name-directory load-file-name))) And then M-x eval-current buffer inside "test1.el", you'll get an error in (file-name-directory load-file-name) because load-file-name is nil. That's why in some cases I needed to use symbol-file of a defined symbol and even failing that "./". > But until now we haven't needed to use such a scheme. > A long time ago I asked why none of the POSIX shells had a debugger. Invariably someone gave an answer that shells are so simple, and an interactive shell is so cool, and "set -x" tracing so awesome that you don't need a debugger. A long time ago I asked why all the media players like xine, mplayer, and vlc rolled their own code with respect to CD handling rather than use a common library; invariably the response I got was that things were better that way. And I seem to recall a lot of consternation over the issue of whether distributed emacs lisp code could span more than one directory. I don't want to get into get into a discussion of how one writes and organizes code, or does program development. The Emacs community is content and I am an outsider here. Please carry on with the great work you have been doing. For my own personal reasons I'd like to understand how close I can get to having something analogous to __FILE__ and require_relative that Ruby has. Thank you for your helping me figure this out and your tolerance of my peculiar style of program development. > > Stefan > --001636c932161f495504781f01bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2009 at 3:17 PM, Stefan = Monnier <m= onnier@iro.umontreal.ca> wrote:
> This is loading relative to the directory I started = at, /tmp/proj/subdir,
> not relative to the directory that of the file that issued the load, > /tmp/proj/test1.el.

You can do

=A0(load (expand-file-name <relativename> (file-name-directory load-f= ile-name)))

Unfortunately this doesn't work ei= ther because load-file-name might sometimes be nil.=A0 For example
where= in test1.el I had:

=A0=A0 (load-file "test3.el")

Using the above suggest= ion, if you change that to

=A0 (load (expand-file-name "test3.= el" (file-name-directory load-file-name)))

And then M-x eval-cu= rrent buffer inside "test1.el", you'll get an error in (file-= name-directory load-file-name) because load-file-name is nil.=A0 That's= why in some cases I needed to use symbol-file of a defined symbol and even= failing that "./".



But until now we haven't needed to use such a scheme.
<= div>
=A0A long time ago I asked why none of the POSIX shells had a debug= ger. Invariably someone gave an answer that shells are so simple, and an in= teractive shell is so cool, and "set -x" tracing so awesome that = you don't need a debugger.=A0 A long time ago I asked why all the media= players like xine, mplayer, and vlc rolled their own code with respect to = CD handling rather than use a common library; invariably the response I got= =A0 was that things were better that way.=A0 And I seem to recall a lot of = consternation over the issue of whether distributed emacs lisp code could s= pan more than one directory.

I don't want to get into get into a discussion of how one writes an= d organizes code, or does program development. The Emacs community is conte= nt and I am an outsider here. Please carry on with the great work you have = been doing.

For my own personal reasons I'd like to understand how close I can = get to having something analogous to __FILE__ and require_relative that Rub= y has. Thank you for your helping me figure this out and your tolerance of = my peculiar style of program development.




=A0 =A0 =A0 =A0Stefan

--001636c932161f495504781f01bd--