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 17:33:54 -0700 (PDT) Message-ID: <7bf7e0e4-1285-4df5-a21c-a279888891e0@default> References: <80273948-1f70-4ec1-abfa-ad0803665c81@default> 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 1503275658 11409 195.159.176.226 (21 Aug 2017 00:34:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 21 Aug 2017 00:34:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 21 02:34:10 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 1djafR-0002JU-KD for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2017 02:34:09 +0200 Original-Received: from localhost ([::1]:48899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djafV-0006Z0-0u for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 20:34:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djafM-0006Xs-Uy for emacs-devel@gnu.org; Sun, 20 Aug 2017 20:34:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djafJ-0002vo-No for emacs-devel@gnu.org; Sun, 20 Aug 2017 20:34:04 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41639) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1djafJ-0002vd-EU for emacs-devel@gnu.org; Sun, 20 Aug 2017 20:34:01 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7L0XvC2005157 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 00:33:57 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7L0Xv7D002513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2017 00:33:57 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v7L0Xt2T022925; Mon, 21 Aug 2017 00:33:55 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: aserv0021.oracle.com [141.146.126.233] 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:217646 Archived-At: > Let me clarify. I see the following spectrum in this debate: >=20 > People who want package.el to be enabled by default in spite of > the resulting UX problems (too much magic, automatic modification > of init-file). >=20 > ^ > | (a) Have Emacs write (package-initialize) into the existing > | init-file at startup. > | > | (b) Have Emacs create a template init-file with > | (package-initialize) at startup, if one doesn't exist > | already. > | > | (c) Don't create (package-initialize) calls anywhere, but still > | call package-initialize in startup.el. > | > | (d) Don't call (package-initialize) anywhere; the user must call > | it manually in their init-file. > v >=20 > People who want package.el to be disabled by default in spite of > the resulting UX problems (package management system doesn't work > out of the box). >=20 > You and I are both at point (d). However, this is a rather extreme > position, so I am not arguing for point (d) or even point (c), but > rather point (b), because I view point (b) as an improvement over > point (a), which is the current situation. >=20 > Most people on this thread view any solution that doesn't involve > package.el working out of the box as a non-starter. That is why I am > not proposing such a solution. Instead, I am proposing a solution > which has much less potential for annoyance, while still having > package.el work out of the box. >=20 > Does this clear up the confusion? I guess so, and I appreciate the time you spent spelling that out. What I would actually prefer, IIUC, is both of these at the same time: * package.el to be enabled by default * package.el to be disabled by default ;-) Rather, as a user I don't want to have to prescribe whether package.el should be enabled or disabled, by default or otherwise. I don't want to have to care about package.el. I would like accessing packages to just happen, when/if I ask to access them - e.g. if I do `M-x list-packages'. And if I have updated whatever persistent info is needed for it, I would like Emacs to automatically enable this or that package when I start Emacs. It should be easy for me to tell Emacs that I prefer to automatically enable this or that package on startup. I would want something like what exists for bookmark.el. If/when you try to access bookmarks then your bookmarks file is loaded automatically. It's on-demand, but your bookmarks file is separate from your init file. > > > 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. >=20 > You're right. I meant that you're arguing that Emacs shouldn't > go through contortions to make package.el work out of the box, Not sure what you mean. I don't care whether Emacs goes through such contorsions. I don't think users should go through contorsions. If by Emacs going through contortions you mean Emacs adding stuff to user init files or creating new init files, then yes, I don't think Emacs should do that. If by Emacs going through contortions you mean that it does some work under the covers then no, I don't care whether it does that. > and people disagree with that. Meanwhile I'm just trying > to make the contortions less horrifying, as an immediate > improvement to the current situation. >=20 > > So I can't say whether your proposal is better or is a > > compromise of some sort. >=20 > The part of my proposal that is relevant to you is the part where > Emacs doesn't try to write (package-initialize) into your init-file > automatically. Do you consider that an improvement? I've already said that I don't think Emacs should write to init files. (And I don't think it should have to do that. Why is that considered a hard requirement?) But I've also said that if the package system needs to record some info persistently for a user then it should use a different file from the init file. That doesn't mean that I disagree with Emacs writing such info locally. It just means hands-off init files, please. > > 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. >=20 > Same here. Unfortunately, the technical challenges in making > package.el work out of the box pretty much guarantee we have > to do one of these. I don't see why. But I don't pretend to be familiar with the technical challenges. If it can do what it needs to do by writing to an init file then why can't it do what it needs to do by using a separate file? Is the problem the difficulty for a user to determine where in the init file to load the separate file? If so, then Emacs can perhaps detect bad placement - not by examining the init file but by the effects of this or that inappropriate placement. E.g., if it is loaded before XYZ has been defined or initialized then tell the user to move it etc. > Now, whether or not it's worth all this trouble to make > package.el work out of the box is another debate, but that's a much > harder debate than this one, which is why I'm not arguing it (at least > for now). >=20 > > I don't see your proposal as a "middle way", for users. >=20 > It's a middle way because creating a default init-file is less > intrusive than modifying an existing one, but still more intrusive > than doing nothing at all. Debatable whether it is less bothersome/intrusive for a user. In any case, I don't argue that Emacs must do nothing at all. I argue (admittedly naively) that Emacs should keep its hands off init files; that's all. =20 > > 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. >=20 > Again, agreed -- but emacs-devel does not want the user to have to > have any understanding of the package system before using it, so I'm ^^^ > not making that argument. I'll make the argument. If Emacs cannot make it easy to use packages without it writing to init files then it sounds like a design flaw and time to get back to the drawing board. > (By the way, you're spot on with the separate Lisp file idea -- in > fact, package.el already does this, and the separate Lisp file > [directory] is ~/.emacs.d/elpa. This debate is over how to force users > to use package.el by activating it automatically. Again, while neither > of us thinks such a thing should be done, I think it's more realistic > to try to get it done in the least bad way possible, at least for > now.) I see. Too bad. > > FWIW, I am also not in favor of Customize writing to your > > init file. > > Same. >=20 > > 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. >=20 > The solution here is improving the documentation of package.el, > which I've already suggested. Even without being familiar with that doc, I can pretty much blindly guess "+1" to that suggestion. But as someone will no doubt point out, lots of users (especially nowadays) do not read doc. Create a good video presenting the same relevant information and that might be all that's needed. That plus making the package system perform some checks to recognize problematic situations resulting from inappropriate use - and then point to relevant videos/doc etc. IOW, if this is about pilot error then (1) improve the pilot doc and (2) add some indicator lights or announcements that pop up telling a pilot about a mistake s?he made and how to correct it. > > I say "naively" because I know next to nothing about > > package.el, and I'm not trying to design the package system. >=20 > As someone who has in fact already written an Emacs package manager > from scratch (straight.el), I think all your points are spot on. > Thanks for your comments. Thank you for your explanations.