[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature Request : autoload-form
From: |
Mike Mattie |
Subject: |
Re: Feature Request : autoload-form |
Date: |
Sun, 30 Mar 2008 14:35:08 -0700 |
On Sun, 30 Mar 2008 12:24:19 +0100
"paul r" <address@hidden> wrote:
> 2008/3/30, Richard Stallman <address@hidden>:
>
> > 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
>
>
signature.asc
Description: PGP signature
- Feature Request : autoload-form, paul r, 2008/03/28
- Re: Feature Request : autoload-form, Stefan Monnier, 2008/03/29
- Re: Feature Request : autoload-form, paul r, 2008/03/29
- Re: Feature Request : autoload-form, Richard Stallman, 2008/03/30
- Re: Feature Request : autoload-form, paul r, 2008/03/30
- Re: Feature Request : autoload-form, Richard Stallman, 2008/03/30
- Re: Feature Request : autoload-form, Stefan Monnier, 2008/03/30
- Re: Feature Request : autoload-form, paul r, 2008/03/30
- Re: Feature Request : autoload-form, Levin Du, 2008/03/31
- Re: Feature Request : autoload-form,
Mike Mattie <=
- Re: Feature Request : autoload-form, Richard Stallman, 2008/03/31
- Re: Feature Request : autoload-form, paul r, 2008/03/31
- Re: Feature Request : autoload-form, Mike Mattie, 2008/03/31