[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: relative load-file

From: Rocky Bernstein
Subject: Re: relative load-file
Date: Sat, 21 Nov 2009 23:45:14 -0500

On Sat, Nov 21, 2009 at 5:52 PM, Richard Stallman <address@hidden> 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, pydbgrrbdbgr, 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-debug in 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__))))))

reply via email to

[Prev in Thread] Current Thread [Next in Thread]