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

[Mike Mattie]

On Tue, Mar 08, 2011 at 04:26:32AM -0600, Ted Zlatanov wrote:
> On Mon, 07 Mar 2011 21:46:10 -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.  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.  What other choice is
> there to modularize .emacs?
> 
> SM> If you're talking about downloading random files containing
> SM> configuration code (so the user doesn't have to create a file, inventing
> SM> a file name for it), then maybe that could make sense, but I haven't
> SM> seen such files very much, and I suspect many of them could easily be
> SM> turned either into themes or into packages installable via package.el.
> 
> Obviously that works for package managers like el-get.
> 
> OK, let's say I have the 8 files I listed earlier (tzz.emacs.*.el).  I
> 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 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?
> 
> On Tue, 8 Mar 2011 01:14:37 -0600 Ben Key <address@hidden> wrote: 
> 
> BK> I am attaching to this message a quick implementation of this feature I
> BK> threw together in about an hour.  I am not familiar with the Emacs package
> BK> mechanism but I am certain that this could be converted to an Emacs 
> package
> BK> without too much work thus making it easier to install.
> 
> On Tue, 08 Mar 2011 02:58:03 -0700 Evans Winner <address@hidden> wrote: 
> 
> EW> For what it's worth, this is the thing I have in my .emacs.
> EW> It does what I want it to, which is just to allow me to
> EW> break my .emacs into various not-excessively-long files
> EW> organized by subject, like email config, org-mode config and
> EW> so-forth.
> 
> Thanks for your code.  Both of your solutions are similar to what I
> would like to use, but Mike Mattie's concerns about startup behavior
> (mainly for daemon mode, for --batch mode, and when there are errors)
> are valid.  The recursion behavior should probably not be the default by
> parallel with other such systems I listed, e.g. /etc/rc.d and Bazaar's
> plugins directory.  It's easy enough to make it optional or to write a
> snippet that loads a specific subdirectory.  The argument I have against
> recursion is that it's hard to tell at a glance what's going to get
> loaded.

I have thought alot about your proposal for automatic loading so that it
is not necessary to edit anything, just drop a file in. There is some
real appeal for that kind of a feature ... but it is hard to implement.

By hard to implement I mean really hard. Just because a file is opened
and written to, it is not necessarily ready to load. I hit C-x s alot
when tweaking files ...

Even if I hacked some kind of inotify support to watch a directory for
IO activity I would never know when to actually load it.

If you can somehow signal when a collection is ready for re-scanning
I can see an implementation ...

> 
> It seems no one thinks prompting about new or changed files in the
> load-dir is worthwhile, so never mind about that part of my proposal.

I don't discount your idea, it's just hard to make a really reliable
implementation IMHO.

> 
> Thanks
> Ted
> 
>

pgplxnnQfReJl.pgp
Description: PGP signature