all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Rocky Bernstein <rocky@gnu.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: relative load-file
Date: Sat, 14 Nov 2009 10:44:01 -0500	[thread overview]
Message-ID: <6cd6de210911140744t75b84417udfa6921cc8fe424f@mail.gmail.com> (raw)
In-Reply-To: <E1N9Gjb-00050e-SZ@fencepost.gnu.org>

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

On Sat, Nov 14, 2009 at 6:24 AM, Richard Stallman <rms@gnu.org> wrote:

> The basic idea of `require' is that you specify a feature which gets
> found through a search of all libraries.  The idea is that these are
> general features which anything might want to use.
>

Require has* two* parts which are distinct. One part has the searching for a
file in it. The other part is the conditional load depending on whether or
not a feature has already been loaded


> You want something different:
>
>    That is, one wants to
>    load an Emacs Lisp file relative the file that issues the load which is
>    often in the same directory or a nearby directory.
>
> It seems to me that this is useful only for loading other parts of one
> single multi-file program.
>

No. A large modular program can be composed of other smaller modular
programs. In theory, one can package each file or subsets of files as their
own package, but often those smaller modules may be custom enough that it
doesn't make sense to do so. Or at least not initially.

However when developing or working on the program, one wants may want to
work with each of the subparts independently.

Here's an example that no doubt you are familiar with: a compile has a
parser, code generator and code optimizer. In a well-written modular
compiler one may want to work on and test the parser as an independent unit
even though I'm not sure you would want to package the front-end for a
specific language independently.

So what require-relative and load-relative allow one to do is create these
little independent units without the overhead of using a more elaborate
packaging systems. require/provide in fact does this too. However it pulls
in file searching which is not desired here. Instead, what we want to do in
a program built of custom modules but is just change how the file searching
is managed.

The second benefit of this is that we can develop out of the source tree
(that is without having to "install" the submodules) and have another
version or many versions "installed" at the same time. Starting with a
member of each version stays within that version of the code.


> If you have a program which is in multiple files, you can write a
> function similar to `require' which searches for files in any way you
> like, and then you can use it.  The function can be in your program;
> it does not need to be built-in.  It can load the chosen file using
> `load'.
>

> The files should each use `provide' in the usual way, and your
> function should use the variable `features' to see if the desired
> feature has already been loaded.  The only difference would be in
> choosing which file to load.
>


That's in fact what I have done<http://github.com/rocky/emacs-load-relative>.
The only "primitive" needed is Ruby's __FILE__  which is the same thing as
the C preprocessor  __FILE__.

$# and load-file-name are close; better is (car-safe current-load-list). How
these differ, and where __FILE__ is better, is that a macro substitution of
the file name is done at compile time inside the code the if compiled, or at
eval time if not.

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

  reply	other threads:[~2009-11-14 15:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-11 17:01 relative load-file Rocky Bernstein
2009-11-11 18:35 ` Tassilo Horn
2009-11-11 19:26   ` Rocky Bernstein
2009-11-11 19:54     ` Tassilo Horn
2009-11-11 20:17     ` Stefan Monnier
2009-11-11 21:21       ` Rocky Bernstein
2009-11-11 23:06         ` Stefan Monnier
2009-11-12  1:01           ` Rocky Bernstein
2009-11-12  1:20             ` Stefan Monnier
2009-11-12  2:09               ` Rocky Bernstein
2009-11-12  4:22                 ` Stefan Monnier
2009-11-12 13:01                   ` Rocky Bernstein
2009-11-12 13:52                     ` spedrosa
2009-11-12 14:11                       ` Andreas Schwab
2009-11-12 15:34                     ` Stefan Monnier
2009-11-13  4:34                       ` Rocky Bernstein
2009-11-13 14:22                         ` Stefan Monnier
2009-11-13 15:03                           ` Rocky Bernstein
2009-11-13 16:17                             ` Stefan Monnier
2009-11-13 16:39                               ` Rocky Bernstein
2009-11-14 11:24 ` Richard Stallman
2009-11-14 15:44   ` Rocky Bernstein [this message]
2009-11-15 21:59     ` M Jared Finder
2009-11-18  3:20       ` Stefan Monnier
2009-11-15 22:38     ` Richard Stallman
2009-11-15 23:50       ` Rocky Bernstein
2009-11-18 12:10         ` Richard Stallman
2009-11-18 13:39           ` Rocky Bernstein
2009-11-21 22:52             ` Richard Stallman
2009-11-22  4:45               ` Rocky Bernstein
2009-11-23  2:29                 ` Richard Stallman
2009-11-23 15:04                   ` Rocky Bernstein
2009-11-24 14:11                     ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2009-11-13  5:24 grischka
2009-11-13  5:59 ` Rocky Bernstein
2009-11-13 14:26   ` Stefan Monnier
2009-11-13 15:06     ` Rocky Bernstein
2009-11-09 14:54 rocky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6cd6de210911140744t75b84417udfa6921cc8fe424f@mail.gmail.com \
    --to=rocky@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.