From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: user-controlled load-path extension: load-dir Date: Tue, 08 Mar 2011 04:26:32 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87oc5lx607.fsf@lifelogs.com> References: <87ei6mz24h.fsf@lifelogs.com> <20110306072147.GA11067@event-horizon.homenet> <871v2i525h.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299580023 32214 80.91.229.12 (8 Mar 2011 10:27:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2011 10:27:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 11:26:57 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pwu7y-0005c0-Qb for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2011 11:26:55 +0100 Original-Received: from localhost ([127.0.0.1]:59789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwu7y-0001u0-90 for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2011 05:26:54 -0500 Original-Received: from [140.186.70.92] (port=53162 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pwu7t-0001pn-0r for emacs-devel@gnu.org; Tue, 08 Mar 2011 05:26:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pwu7r-0005cj-KJ for emacs-devel@gnu.org; Tue, 08 Mar 2011 05:26:48 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:57292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pwu7r-0005cX-AT for emacs-devel@gnu.org; Tue, 08 Mar 2011 05:26:47 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pwu7p-0005XX-1W for emacs-devel@gnu.org; Tue, 08 Mar 2011 11:26:45 +0100 Original-Received: from c-67-186-102-106.hsd1.il.comcast.net ([67.186.102.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Mar 2011 11:26:45 +0100 Original-Received: from tzz by c-67-186-102-106.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Mar 2011 11:26:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-67-186-102-106.hsd1.il.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:VWTEEU6xZAcNmByNc6xWJDhu4sc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136883 Archived-At: On Mon, 07 Mar 2011 21:46:10 -0500 Stefan Monnier 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 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 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. 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. Thanks Ted