Re: user-controlled load-path extension: load-dir

[Stefan Monnier]

>>> I think this proposal is really about code snippets that people would
>>> otherwise just cut and paste into their .emacs file.  The average
>>> user's .emacs often winds up containing mostly code they found
>>> somewhere and use without really understanding it.  Dropping each
>>> snippit in its own file would be a big help if the user ever did need
>>> to debug some problem with his init, or if he decided one day to
>>> actually learn elisp.

SM> I'm far from convinced it's better for people to drop random chunks of
SM> configuration into separate files rather than all in the .emacs file.

> It's not "better," it's what people already do.

I must be missing something.  I see two different things on the web:
packages on the one hand and Elisp configuration chunks on the other.
The first come in files you can download, the other comes in
<pre>...</pre> elements in HTML pages which you can copy&paste.
My claim is that the first can be better handled by package.el or themes
and the other works just fine in .emacs.

> Emacs would just make it easier than the current situation, which is
> to drop a file plus edit the .emacs every time a file is added or
> deleted.

If you drop the file with package.el you don't need to edit the
.emacs correspondingly.

> want to load them modularly.  So I put them in the load-dir.  Do I have
> to make 8 packages?  And every time I update one of those files, do I
> have to repackage it with a new version?  That seems workable but
> tedious compared to the code proposed by Ben Key and Evans Winner.

If you're really talking about configuration code rather than packages,
then I tend to assume that people whose .emacs is so large as to need
modularization can figure out which kind of modularization they want and
implement (or copy&paste) the corresponding loop to load the various files.

I'm not even sure why you'd want to "modularize" in this way: my .emacs
was fairly large but splitting it into separate files never seemed like
a good way to help, since I'd then have to figure out how to make C-s
and M-/ find matches in neighboring files.  Instead I "split" it with
outline-minor-mode.

> If you're against including the load-dir in the core and enabling it by
> default, how about making it a GNU ELPA package so it's easily
> installable?

Such a package would be perfectly acceptable, yes.


        Stefan