On Sun, 30 Mar 2008 12:24:19 +0100
"paul r" <paul.r.ml@gmail.com> wrote:

> 2008/3/30, Richard Stallman <rms@gnu.org>:
> 
> > I don't think we should install this in Emacs, though.  Something
> > like autoload should be kept simple and limited.
> 
> I think of autoload as a particular case of the general need to
> "eval-on-event-then-call". Therefore, I do not see why evaluating a
> form is less simple than loading a file. Form evaluation is, indeed,
> less limited but I don't see why it should be a disadvantage here.
> 
> >  If loading a certain file needs load-path to be set a certain way,
> >  the user should simply set load-path that way, perhaps in .emacs.
> >  It is a bad idea to have files that only work right if load-path
> >  is temporarily changed; rather than adding a new file to Emacs
> >  to cope with that situation, it would be better to redesign the
> >  Lisp code that appears to need it.
> 
> You are understanding most of the problem I'm facing. I'll try to give
> you some more information in a manner as concise as possible.
> I wrote a system called TidyConfig for emacs. It is not a mode, it is
> a system. Its ultimate goal is to allow people to share effectively
> what usualy resides in .emacs. Some people want to do that, because
> they have very similar usage profiles, although not exactly the same.
> Users copies can be synced using a DVCS. The best example I see is
> people in my company, who all use TidyConfig and this way avoid
> duplicated efforts. To achieve that :
>   - I got rid of the monolithic .emacs, so that bits of configuration
> go into dedicated "modules". There is a module for C-mode, one for
> Muse-mode etc. One module resides in one file. Modules are shared in
> your network of friends/colleagues ... anybody syncing with you, so
> they are "network-specific" but not "user-specific".
>   - To allow fine-tuning, a user can use "module configuration file",
> which is an other file, with personal tweaking in it. Those conf files
> are not shared and are usually optional. They are user specific, and
> private. Exemple : the ERC module does a lot of configuration, but it
> can not set up username, password etc because this information is
> user-specific.
> 
> Any module is optional, this is the whole point of this project. Each
> user simply choose in a list what modules he wants to use. He can
> chose to load them at startup time, or "later when needed". In this
> last case, I obviously use autoload.
> 
> I could put, at beginning of *every* modules, a (load-file
> "thisModuleConfigurationFile" t). This is what I did before, but I do
> not find that elegant, nor fully satisfactory in many ways for the
> needs, so it now is to the TidyConfig system to carry proper loading
> of modules.
> 
> Here we are. I currently have no option to do so, except putting the
> form I want to eval in a dummy file and registering this file with
> autoload. This is now what I do, and please believe I don't feel
> pround of that ugly hack :)
> 
> If you want to visit my upstream TidyConfig repository, and why not
> give it a try, you can go to
> http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is
> versionned through mercurial, so you can also do a "hg clone" of this
> url. It could maybe be used as a playground for people here to try and
> share some lisp before checking in into the trunk, and also to get
> hands on DVCS. There is an up to date documentation in english.
> 
> Hope that was not too long ... Thanks.

I wrote something very similar, but different on some design points. It boiled down
to my "modules" having a three part form:

[define meta-data & hooks ]

[ load w/require ]

[ setup ]

I would define things like install hooks before the loading part. If anything went wrong with loading
needed libraries, my load function could execute the install hooks, and re-evaluate the module.

loading would be a bunch of require forms.

The setup would configure and integrate the features.

If you want to know more drop me a mail off-list.

> -- Paul
> 
>