Re: Feature Request : autoload-form

["paul r" <paul.r.ml@gmail.com>]

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.

-- Paul