From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Summary and next steps for (package-initialize) Date: Sun, 20 Aug 2017 11:09:50 -0700 (PDT) Message-ID: <80273948-1f70-4ec1-abfa-ad0803665c81@default> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1503252609 25052 195.159.176.226 (20 Aug 2017 18:10:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 18:10:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 20:10:02 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djUfi-00063l-1D for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 20:10:02 +0200 Original-Received: from localhost ([::1]:44994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djUfo-0006LP-4P for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 14:10:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djUff-0006Kl-8C for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:10:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djUfc-0008LP-1f for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:09:59 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:39071) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1djUfb-0008LA-On for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:09:55 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7KI9q25003119 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 20 Aug 2017 18:09:53 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7KI9p3F027341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 20 Aug 2017 18:09:52 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7KI9p3J021551; Sun, 20 Aug 2017 18:09:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6774.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217642 Archived-At: > > Personally, I don't think Emacs should be generating init files > > in any case. And certainly not generating an init file that > > does something with the package system. Emacs should continue > > with the point of view that you start it, by default, with no > > init file - no code at all. Nada. >=20 > I agree wholeheartedly with everything you have said. However, a > significant number of people on this list disagree, Hm. I haven't read this thread very carefully. But I also haven't gotten the impression that a significant number of people here have argued for generating init files. Not at all. And I haven't gotten the impression that the default behavior should be to start Emacs with no init file. So I don't quite follow you there. > which is why I have made a middle-of-the-road proposal > that is more likely to be accepted. By "middle-of-the-road" are you perhaps referring to the fact that you, like I, don't like Emacs messing with an existing init file in order to try to tame package.el? Is that what you meant? If not, I don't see anything one might call "middle" about what (I understand of) your proposal. > Do you agree that my proposal (only an init-file generated if one > doesn't exist) is at least better than the current situation > (hand-written init-file is modified programmatically by Emacs)? Honestly, I'm not qualified to speak about solutions for package.el problems. I don't use the package system, myself. So I can't say whether your proposal is better or is a compromise of some sort. I don't like the idea of Emacs generating an init file if there is none OR of Emacs messing with an existing init file. Sounds like a choice between being burned in the frying pan or burned in the fire. I don't see your proposal as a "middle way", for users. (It may be a middle way of sorts for designers of the package system; dunno.) > I'd like to fix the brokenness of the current situation before > trying to move towards the best possible solution. If we accept > this proposal, we could later think about things like removing > (package-initialize) from the template init-file (although I > doubt this will happen anytime soon, if ever, based on the > feedback I got). Doesn't sound like a great plan, to me. But again, mine is just one opinion, from someone who is not very familar with the package system. Naively, I'd suggest that package.el should do what custom.el and bookmark.el and lots of other libraries do: Use a separate Lisp file for persisting info the library needs - a file whose name/location the user can set using an option. If that would mean that a user might need to load that file at an appropriate place in an init file, so be it. The package system might well require some understanding of it before using it. Customize is a bit like that: If you use a `custom-file' then it is up to you to load it at an appropriate place in your init file. If you don't use a `custom-file' then you don't need to worry about finding the most appropriate such place. (But then you need to worry about crosstalk between manual and automatic edits - not worth it.) (FWIW, I am also not in favor of Customize writing to your init file. I would prefer that we not only encourage use of `custom-file' but we make it mandatory. bookmark.el has it right: require the use of a separate file.) If it is difficult for users to find an appropriate place in their init file to load whatever state/settings file package.el might require, or to call `package-initialize' or whatever, then perhaps the package system could be improved to help with that somehow. I say "naively" because I know next to nothing about package.el, and I'm not trying to design the package system. I have little to contribute here, other than a wish, as one user, not to have the package system mess with me or complicate things for users generally. I have faith that there is a way to do things sanely for package.el, even if I don't have such a sane design to offer.