From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: relative load-file Date: Wed, 11 Nov 2009 23:22:06 -0500 Message-ID: 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: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1257999747 8390 80.91.229.12 (12 Nov 2009 04:22:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2009 04:22:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 05:22:20 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 1N8RCN-0007Mj-Uy for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2009 05:22:20 +0100 Original-Received: from localhost ([127.0.0.1]:33551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8RCN-0006q2-3M for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2009 23:22:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8RCH-0006mz-Ec for emacs-devel@gnu.org; Wed, 11 Nov 2009 23:22:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8RCC-0006j8-Sw for emacs-devel@gnu.org; Wed, 11 Nov 2009 23:22:13 -0500 Original-Received: from [199.232.76.173] (port=37850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8RCC-0006j1-Mk for emacs-devel@gnu.org; Wed, 11 Nov 2009 23:22:08 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:35757 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8RCB-0002bH-5C; Wed, 11 Nov 2009 23:22:07 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEADcc+0pMCpsp/2dsb2JhbACBTtsPhDwEiSM X-IronPort-AV: E=Sophos;i="4.44,726,1249272000"; d="scan'208";a="49152653" Original-Received: from 76-10-155-41.dsl.teksavvy.com (HELO pastel.home) ([76.10.155.41]) by ironport2-out.pppoe.ca with ESMTP; 11 Nov 2009 23:22:06 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 696D88373; Wed, 11 Nov 2009 23:22:06 -0500 (EST) In-Reply-To: <6cd6de210911111809j526ce8bfmcb5d57f907afff96@mail.gmail.com> (Rocky Bernstein's message of "Wed, 11 Nov 2009 21:09:58 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:116863 Archived-At: > 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. 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. 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. > First, none of the examples I have given do I find really corner case. They work fine with the above code. > 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. > 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. Stefan