Re: relative load-file

[Rocky Bernstein <rocky@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

On Sat, Nov 21, 2009 at 5:52 PM, Richard Stallman <rms@gnu.org> 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
<http://github.com/rocky/emacs-dbgr>package for GNU Emacs. Some files
are specific to specific debuggers (
bashdb <http://bashdb.sourceforge.net/>,
remake<http://github.com/rocky/remake>,
pydbgr <http://code.google.com/p/pydbgr/>,
rbdbgr<http://github.com/rocky/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-debug<http://rubyforge.org/projects/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 <http://github.com/rocky/emacs-load-relative>.

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__))))))

[-- Attachment #2: Type: text/html, Size: 4699 bytes --]