emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ted Zlatanov
Subject: Re: user-controlled load-path extension: load-dir
Date: Tue, 08 Mar 2011 15:38:02 -0600
User-agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux)

On Tue, 08 Mar 2011 15:59:51 -0500 Stefan Monnier <address@hidden> wrote: 

>>>> 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.

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

There is a third class: streams (or snippets) of code I don't want to
keep inside my .emacs because I don't like to make it big.  There are
some users who will use and enjoy this functionality, even if other
users won't.  As I proposed it, it will be off by default so it only
benefits those who enable it and won't harm those who don't.

This kind of modularization doesn't make it to the web as much because
it's usually specific to the user's needs.  Here are some examples:

http://www.emacswiki.org/emacs/JoelAdamson#toc5
http://www.io.com/~jimm/emacs_tips.html#my-dot-emacs
http://www.emacswiki.org/emacs/DotEmacsModular
https://github.com/technomancy/emacs-starter-kit
http://www.emacswiki.org/emacs/InitSplit
http://stackoverflow.com/questions/2079095/how-to-modularize-an-emacs-configuration

It's a common need as you can see.

In the Emacs core it will be easier to enable it, that's all.  Otherwise
the instructions have to be "install package load-dir, THEN do the rest"
which is a bit more work, requires a network connection, etc.

>> 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.

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

Yes, but you're assuming managing configuration modules in monolithic
Emacs Lisp is the best way.  Give us something simple and easy to manage
the loop at the filesystem level, so we don't have to write it
ourselves.

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

For me it works better.  I like small files; outline-minor-mode and
folding-mode don't work for me.  I suspect I'm not the only one.  See
the URLs above for a list of similar needs.

>> 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?

SM> Such a package would be perfectly acceptable, yes.

I'll work with Ben Key to do this in a package if you and Chong Yidong
reject this functionality from the Emacs core.

Ted




reply via email to

[Prev in Thread] Current Thread [Next in Thread]