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: Sat, 21 Nov 2009 23:45:14 -0500 Message-ID: <6cd6de210911212045q21a4080bxdb1073b64a4cc5cb@mail.gmail.com> References: <6cd6de210911110901v24307163i253e69e89c72c9e@mail.gmail.com> <6cd6de210911140744t75b84417udfa6921cc8fe424f@mail.gmail.com> <6cd6de210911151550v6f66c1begdbcda315f6f8edf5@mail.gmail.com> <6cd6de210911180539j6c921924t36a8eeda3a5a22fb@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00504502b738f96c2c0478ee5f58 X-Trace: ger.gmane.org 1258865139 13470 80.91.229.12 (22 Nov 2009 04:45:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2009 04:45:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 05:45: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 1NC4KJ-0007qM-OX for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 05:45:32 +0100 Original-Received: from localhost ([127.0.0.1]:51108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC4KJ-0005kp-61 for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 23:45:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NC4KC-0005hY-0i for emacs-devel@gnu.org; Sat, 21 Nov 2009 23:45:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NC4K7-0005gS-CZ for emacs-devel@gnu.org; Sat, 21 Nov 2009 23:45:23 -0500 Original-Received: from [199.232.76.173] (port=47256 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC4K7-0005gP-6M for emacs-devel@gnu.org; Sat, 21 Nov 2009 23:45:19 -0500 Original-Received: from mail-px0-f189.google.com ([209.85.216.189]:50707) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NC4K3-0001gY-Qu; Sat, 21 Nov 2009 23:45:16 -0500 Original-Received: by pxi27 with SMTP id 27so3134055pxi.25 for ; Sat, 21 Nov 2009 20:45:14 -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=JlCMBw8N3Ye3lX1vIyxteNcCnxWwBILN3T9bDa0bgPE=; b=BhMm16kCXxPvp7jN1E5p6BtUgJD2vxuRJA7F0YAjHi0c9NaCFI/5AgPwWHfAN3Umjv dlvNJ2jmpZzqYFG4knfljnz4RvjqPIAlc80XUa2V/R2lfClrqhYJWu2obVbiGUTzBKG1 hVgA0kadQm9rbaFKJ0jaZPtMQijUyEtLjbxoI= 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=Vt1YJVa/9j7phyFFMLrFk3PcvMUrqpydlsPcRva+tqrkCLrutzCRjeH3SNppMJc+Px sE1Ao+mPAAZUq8G6Ym2Ph/xipG3HnUGV4e01ytZ/Sil0DjsO2LOkVIfbyfafyI6FZbTh jEPp0gG8Lg3JwJvNVhT78NCC3uXjUGDsAGTqI= Original-Received: by 10.142.9.34 with SMTP id 34mr344170wfi.114.1258865114573; Sat, 21 Nov 2009 20:45:14 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 4a979ebd636ca951 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:117483 Archived-At: --00504502b738f96c2c0478ee5f58 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 21, 2009 at 5:52 PM, Richard Stallman wrote: > I now have a better idea of what you're trying to do, and why you want > this to be relative. > > However, it seems to me that a slightly different relative construct > might be better. Instead of relative to "this file". it could be > relative to "this package's top directory". To identify a directory > as counting in this way, you'd put a certain file name in it. Emacs > would find the containing directory which has that name. Then you > could specify a file name relative to that directory. > > What do you think of that? > I don't think it as good for a couple of reasons. First, it seems like a little more work that isn't strictly needed - adding that file. Second, as files move over the course of the lifetime of a project, this scheme will *always* require changing files more often than what I proposed . Here is an example based on experience so far. I am working on a debugger front end package for GNU Emacs. Some files are specific to specific debuggers ( bashdb , remake, pydbgr , rbdbgr, etc.). For now, I find it convenient to split the parts of the Ruby debugger *rbdgr* into several of files: *rbdbgr-core*, *rbdbgr-track-mode*and *rbdbgr*. *rbdbgr* requires *rbdbgr-track-mode* and *rbdbgr-core*. * rbdbgr-track-mode* requires *rbdbgr-core*. Initially life was good. But then as I started adding more code and more debuggers, I wanted to have Ruby debugger code in a separate Ruby folder. With the scheme I am currently using, I don't have to change the requires when they stay the same relative to other required files: *rbdbgr* still requires *rbdbgr-core* and *rbdbgr-track-mode* which were located in the same directory and continue to be so. Irrelevant is how they are accessed from the top. But the scheme you propose, I think I would have had to change the *require* string. Right now, I am planning on putting code for a second debugger ruby-debugin the Ruby directory. Given this change, perhaps I want a directory for each debugger. Perhaps that is off of the top-level, or perhaps this is another directory underneath Ruby. Again with the scheme I currently use, there are fewer changes which makes it easier for me to try out the various possibilities. If there is a __FILE__ variable/macro/function, implementing what I propose is very simple. Aside from lingering the bugs that I will discover and fix over time, what I want is done. But here's another neat thing that I just realized one can do using __FILE__ (or an extended load-file-name if you prefer). I've just added that to the load-relative package . Rather than use: (provide '*feature-name*), via __FILE__ one can write a * provide-me* macro that allows you to omit having to give the feature name if it is the same as the file's base name sans directory. (Personally, I think using this file/feature naming convention is generally a good idea). The macro is short and simple. So here it is: (defmacro provide-me () "Call `provide' with the feature's symbol name made from the source-code's file basename sans extension. For example if you write (provide-me) inside file ~/lisp/foo.el, this is the same as writing: (provide 'foo)." `(provide (intern (file-name-sans-extension (file-name-nondirectory (__FILE__)))))) --00504502b738f96c2c0478ee5f58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Nov 21, 2009 at 5:52 PM, Richard= Stallman <rms@gnu.org<= /a>> wrote:
I now have a better idea of what you're trying to do, and why you want<= br> this to be relative.

However, it seems to me that a slightly different relative construct
might be better. =A0Instead of relative to "this file". it could = be
relative to "this package's top directory". =A0To identify a = directory
as counting in this way, you'd put a certain file name in it. =A0Emacs<= br> would find the containing directory which has that name. =A0Then you
could specify a file name relative to that directory.

What do you think of that?=A0

I don't think it= as good for a couple of reasons.

First, it seems like a little mor= e work that isn't strictly needed - adding that file.

Second, as= files move over the course of the lifetime of a project, this scheme will = always require changing files more often than what I proposed . Here= is an example based on experience so far.

I am working on a debugg= er front end package for GNU Emacs. Some files are specific to specific= debuggers (bashdb, remake, pydbgr,=A0 rbdbgr, etc.).=A0 For now, I find it convenient to split the parts of = the Ruby debugger rbdgr into several of files: rbdbgr-core, <= i>rbdbgr-track-mode and rbdbgr. rbdbgr requires rbdbgr= -track-mode and rbdbgr-core. rbdbgr-track-mode requires <= i>rbdbgr-core. Initially life was good. But then as I started adding mo= re code and more debuggers, I wanted to have Ruby debugger code in a separa= te Ruby folder.

With the scheme I am currently using, I don't have to change the re= quires when they stay the same relative to other required files: rbdbgr<= /i> still requires rbdbgr-core and rbdbgr-track-mode which we= re located in the same directory and continue to be so. Irrelevant is how t= hey are accessed from the top. But the scheme you propose, I think I would = have had to change the require string.

Right now, I am planning on putting code for a second debugger ruby-debug in the Ruby d= irectory. Given this change, perhaps I want a directory for each debugger. = Perhaps that is off of the top-level, or perhaps this is another directory = underneath Ruby. Again with the scheme I currently use, there are fewer cha= nges which makes it easier for me to try out the various possibilities.

If there is a __FILE__ variable/macro/function, implementing what I pro= pose is very simple. Aside from lingering the bugs that I will discover and= fix over time, what I want is done.

But here's another neat thi= ng that I just realized one can do using __FILE__ (or an extended load-file= -name if you prefer).=A0 I've just added that to the load-relative package.

Rather than use: (provide 'feature-name), via=A0 __FILE__ on= e can write a provide-me macro that allows you to omit having to giv= e the feature name if it is the same as the file's base name sans direc= tory. (Personally, I think using this file/feature naming convention is gen= erally a good idea). The macro is short and simple. So here it is:

(defmacro provide-m= e ()
=A0 "Call `provide' with the= feature's symbol name made from
the source-code's file basename sans extension. For example if you
write (provide-me= ) inside file ~/= lisp/foo.el, this is the same as
writing: (provide 'foo)."
=A0 `(p= rovide (intern (file-name-sans-extension
=A0=A0=A0 =A0 (file-nam= e-nondirectory (__FILE__))))))


--00504502b738f96c2c0478ee5f58--