From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: user-controlled load-path extension: load-dir Date: Thu, 10 Mar 2011 16:08:15 +0900 Message-ID: <87oc5jo3kw.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <877hc8nk2h.fsf@lifelogs.com> <87hbbby82y.fsf@uwakimon.sk.tsukuba.ac.jp> <87aah3va9n.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1299740755 19435 80.91.229.12 (10 Mar 2011 07:05:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 10 Mar 2011 07:05:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 10 08:05:51 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 1PxZwT-0005p9-94 for ged-emacs-devel@m.gmane.org; Thu, 10 Mar 2011 08:05:49 +0100 Original-Received: from localhost ([127.0.0.1]:58394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxZwS-0007gC-HC for ged-emacs-devel@m.gmane.org; Thu, 10 Mar 2011 02:05:48 -0500 Original-Received: from [140.186.70.92] (port=43716 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxZwJ-0007g4-99 for emacs-devel@gnu.org; Thu, 10 Mar 2011 02:05:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxZwH-0001zt-TU for emacs-devel@gnu.org; Thu, 10 Mar 2011 02:05:39 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:59795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxZwH-0001zG-AI for emacs-devel@gnu.org; Thu, 10 Mar 2011 02:05:37 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1B0DD9706AB; Thu, 10 Mar 2011 16:05:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 39F181A2749; Thu, 10 Mar 2011 16:08:15 +0900 (JST) In-Reply-To: <87aah3va9n.fsf@lifelogs.com> X-Mailer: VM 8.1.93a under 21.5 (beta29) "garbanzo" f5a5501814f5 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:137025 Archived-At: Ted Zlatanov writes: > There's a lot of "daddy knows best" packed in your definition, isn't > there? Of course. That's what a maintainer does, make these kinds of decisions about what's best for everybody. That is the point of view I'm taking, not trying to evaluate the feature on its own terms. > I have not advocated [automatically installing and loading code] > and am against it; if I implied otherwise I apologize for the > misunderstanding. el-get's *bootstrap* may reside in the load-dir, > but all the packages it manages won't. >From the maintainer's point of view, this is *not about you*. You have restrained requirements for the feature, yes. How do you propose to impose *your* restraints on *others* who want additional features, though? > SJT> Again, *this is not theory*. This is based on more than a decade > SJT> of experience with such systems in XEmacs. Users do *not* view > SJT> this as "oh, I messed up again". They view it as "if Emacs is not > SJT> going to do it right, it should tell me to do it myself." > > I view it as "I enabled the load-dir feature, maybe I should understand > it." Again, how do you propose to get all other users to view it that way? If this is only for you, you already know how to do it. Obviously, you expect this to be used by many people. It needs to meet their expectations as well as yours, or it's a bad idea to maintain it in core. It is my opinion, based on experience, that requests for more automation will come up over and over again. Similarly, requests for support when code that users throw into the pot conflicts with code already there will come up over and over again. I don't think this feature is worth inducing those requests, that's all. > You keep insisting on holding the user's hand. No. I'm anticipating what *some* users are going to expect of it, based on experience with maintaining similar features. I wouldn't hold the user's hand in this case, I'd simply insist that the feature be provided as a package. Then helping them with their misconceptions (and statistically speaking, there will be a certain fraction of users who misunderstand) is my privilege as core maintainer, not my responsibility. Putting it in core makes it the other way around, and that will suck for Stefan and Yidong IMO. > FWIW XEmacs rewrote and broke my .emacs without prompting last time I > had to use it to debug a Gnus problem, so I'm pessimistic about the way > it holds the user's hand. Bingo! That's exactly the result of the kind of feature creep I'm worred about here, that I described as a mistake, which I now regret not opposing more vehemently at the time, and which I am still not in a position to unilaterally roll back. And whatever happened to your "I enabled it, I should understand it" view? XEmacs was supposed to be a drop-in replacement for Emacs; you shouldn't be surprised that it uses .emacs as its init file and its custom-file if it finds it and custom-file isn't explicitly set, just like Emacs does. If you had spent the time to think about the implications of what you were doing, I should think that "xemacs -q"[1] would be the obvious thing to use to debug Gnus. After all, the person who reported the bug certainly wasn't using *your* .emacs in *her* XEmacs. But that's not the way you think about it, clearly. And guess what? You're right not to think about it that way, just as the users who won't think so carefully about a trivial feature like load-dir are right for them. Life is too short. Footnotes: [1] Which causes both user-init-file and custom-file to be nil, so no accesses, let alone writes, to .emacs would occur.