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: Wed, 09 Mar 2011 13:57:26 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <877hc8nk2h.fsf@lifelogs.com> References: <87ei6mz24h.fsf@lifelogs.com> <20110306072147.GA11067@event-horizon.homenet> <871v2i525h.fsf@lifelogs.com> <87oc5lx607.fsf@lifelogs.com> <874o7ds37p.fsf@lifelogs.com> <4D7726E8.5090206@swipnet.se> <4D772988.4070209@gmail.com> <4D775002.8050100@swipnet.se> <874o7cjj8h.fsf@uwakimon.sk.tsukuba.ac.jp> <87tyfcnon1.fsf@lifelogs.com> <871v2gjdhf.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1299700681 29725 80.91.229.12 (9 Mar 2011 19:58:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2011 19:58:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 20:57:54 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 1PxPW6-00029f-1C for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2011 20:57:54 +0100 Original-Received: from localhost ([127.0.0.1]:53912 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxPW5-00037g-IK for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2011 14:57:53 -0500 Original-Received: from [140.186.70.92] (port=49722 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxPVw-00035D-JX for emacs-devel@gnu.org; Wed, 09 Mar 2011 14:57:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxPVu-0001ai-RO for emacs-devel@gnu.org; Wed, 09 Mar 2011 14:57:44 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:35094) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxPVu-0001a5-Ge for emacs-devel@gnu.org; Wed, 09 Mar 2011 14:57:42 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PxPVq-00020O-EL for emacs-devel@gnu.org; Wed, 09 Mar 2011 20:57:38 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Mar 2011 20:57:38 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Mar 2011 20:57:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 106 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 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:3Egbn6C0+RgQxOIZzW5nLgsNkvE= 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:136986 Archived-At: On Thu, 10 Mar 2011 04:33:16 +0900 "Stephen J. Turnbull" wrote: SJT> Ted Zlatanov writes: >> On Thu, 10 Mar 2011 02:29:02 +0900 "Stephen J. Turnbull" wrote: >> SJT> I can only imagine that a load-dir would very likely be the source SJT> of numerous bugs as some snippets conflict with or depend on others SJT> but the automatic loader gets them in the wrong order. >> >> We're just adding a mechanism for easy personal code deployment and >> modularization, not a cure for broken code. SJT> There's no broken code here, just code not engineered with automatic SJT> loading in mind. By your logic out-of-order startup scripts in /etc/rc.d should be managed with an external system because simple shell scripts are not engineered with automatic loading in mind. Sometimes things really are independent and you have to trust the user. SJT> Ie, it's the idea of automatically loading random snippets that is SJT> broken: it's a mechanism for speeding up the mess, as Robert SJT> Townsend put it. I don't think that belongs in core, but rather SJT> should be an individually maintained function, tuned to each SJT> person's requirements. OK, thank you for your opinion. SJT> As for easy personal code deployment and modularization, there's SJT> nothing that says that deployment and modularization requires SJT> implementation as separate files, and in fact using separate files for SJT> most things that you would do in an init file is an annoyance as SJT> Stefan points out. Stefan's recommendation of using outline minor SJT> mode easily scales to a 100kB file for me in other contexts, I imagine SJT> it would work fine for the init file. While I admit YMMV as a user, SJT> from the point of view of Emacs maintainers this blows away the SJT> load-dir idea in terms of maintainability of Emacs core. OK. What reasons do you have to NOT include the load-dir functionality in the core if it's disabled by default and must be consciously enabled? That you're happy without it? SJT> Note that the good reasons for using separate files (assuming you use SJT> an editor that supports things like outline minor mode -- you do, SJT> don't you?) are not really compatible with automatic SJT> installation and loading. They're things like lazy loading and SJT> optional loading to avoid memory bloat and namespace pollution. Lazy SJT> loading could be a win (somebody mentioned autoloading instead of SJT> automatic loading at init time), therefore, but guess what? that SJT> requires reading code and deciding where to put autoload cookies. For me those reasons are modularization and easy code deployment on a personal level. I think I've been clear on that and wonder how you determined your reasons were the good ones. SJT> Note also that .d directories generally use some convention (such as SJT> file names starting with fixed width integers) that ensure that SJT> snippets sort in the right order. >> >> I'm sure users can use that (I will). But they can also specify the >> order with explicit loads if that's what they need. SJT> Neither of those is easy or automatic. To the extent that such are SJT> needed, people are going to have to sit down and read code to figure SJT> out what the problems are. That's precisely what the system is SJT> supposed to avoid. Who said load-dir is supposed to avoid problems? As with the earlier comment about broken code, if you screw up your configuration layout in any form, you go and fix it. Emacs should indicate where the error happened, but beyond that it's a user issue. SJT> Note that you also have a problem that such explicitly loaded files SJT> will often need to be moved out of the load-dir, as they won't be SJT> designed to be idempotent. Mostly not a problem, of course, and SJT> therefore all the more annoying and confusing when it does arise. Sorry, I don't follow. Can you give a specific example? SJT> More modern systems use (please sit down, you're in for a shock) SJT> full-blown dependency systems (requires, provides, conflicts, etc) SJT> in the snippets, which avoids the need to maintain explicit order SJT> in favor of a partial order. >> >> That's, again, overengineering the problem (as Mark Twain put it, "with >> all the modern inconveniences"). SJT> Well, no, it's not. The problem in question is maintaining a .d SJT> directory without requiring the user to have a clue. NO IT'S NOT! Why are you assuming you must treat the user like an idiot who doesn't know he put a file in a directory and can't figure out load dependencies? If the user wants hand-holding, he will use Customize and package.el and el-get and all the other marvels of the modern age. I prefer not to, for my own snippets I will write. SJT> If Stefan and Yidong could get away with "Ted Z says that's SJT> overengineering so we ain't gonna touch it", it might be worth SJT> putting this in core. But my recommendation to them is "snippet SJT> conflicts are going to be a persistent annoyance in the long term; SJT> let Ted Z and Jan D maintain a package and deal with the PEBKACs SJT> and RFEs." OK, got it. Thanks. Ted