Re: An alternative to a monolithic ~/.emacs init file

[rustom <rustompmody@gmail.com>]

On Nov 10, 10:13 pm, Tom Tromey <t...@tromey.com> wrote:
>
> ELPA works this way, more or less.  It isn't as simple as "drop in some elisp and work"

Thanks Tom. I checked out elpa and also install-elisp.  Considering we
are living in the age of SOA -- think of the success of things like
apt in the linux world or eggs in python gems in ruby  -- I suppose
its the in thing to be able to directly install an elisp file from a
web archive.

What I am looking for is something different:
- I have a bunch of my own customizations and autoloads rather than
ready made packages
- I of course want to autoload n rather than load n (for large n)
- The customize generated stuff only makes it much worse and more
monolithic.
- The .emacs file tends to become a kitchen sink kind of mess.

All this is not merely a question of aesthetics -- I like to sell
emacs to people but if I show a typical .emacs people would just run
away.

Note Francisco's solution does not separate out the autoload time from
the load time -- the basic problem as I see it.

So I am looking at an approach to distributing this kitchen
sink .emacs across different 'drawers' , each drawer (folder)
containing

1. autoloads loaded at emacs start time
2. customizations 'hooked' to the feature. [Admission: I dont
understand customizations very well]
3. the feature itself (This is usually absent because its a standard
mode in a standard place like cc-mode or python-mode etc)

I could of course write this infrastructure myself but I would be very
surprised if it had not already been written many times over before.