[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user-controlled load-path extension: load-dir
From: |
Mike Mattie |
Subject: |
Re: user-controlled load-path extension: load-dir |
Date: |
Tue, 8 Mar 2011 22:03:34 -0800 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
- Re: user-controlled load-path extension: load-dir, (continued)
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Stephen J. Turnbull, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Stephen J. Turnbull, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/10
- Re: user-controlled load-path extension: load-dir, Stephen J. Turnbull, 2011/03/10
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/10
- Re: user-controlled load-path extension: load-dir, Stephen J. Turnbull, 2011/03/10
- Re: user-controlled load-path extension: load-dir, Mike Mattie, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Jan Djärv, 2011/03/10
- Re: user-controlled load-path extension: load-dir,
Mike Mattie <=
- Re: user-controlled load-path extension: load-dir, Jan D., 2011/03/09
- Re: user-controlled load-path extension: load-dir, Mike Mattie, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Mike Mattie, 2011/03/07
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/08
- Re: user-controlled load-path extension: load-dir, Mike Mattie, 2011/03/09
- Re: user-controlled load-path extension: load-dir, Ted Zlatanov, 2011/03/09
Re: user-controlled load-path extension: load-dir, Ben Key, 2011/03/08
RE: user-controlled load-path extension: load-dir, Ben Key, 2011/03/08