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: Thu, 24 Aug 2017 10:44:09 -0700 (PDT) Message-ID: References: < <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <2d035e42-006b-e76e-2b3f-75f2dfd87bb7@taydin.org> <58ac4c14-3f26-4b21-806a-aa2326ce3d2b@default> <98f114b6-191e-43f9-b505-9362b9382508@default>> <<83fucg99cj.fsf@gnu.org>> 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 1503596736 6940 195.159.176.226 (24 Aug 2017 17:45:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 17:45:36 +0000 (UTC) Cc: radon.neon@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 19:45:30 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 1dkwBz-0000u8-5i for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 19:45:19 +0200 Original-Received: from localhost ([::1]:49692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwC6-0001iV-1T for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 13:45:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwB4-0001HA-8r for emacs-devel@gnu.org; Thu, 24 Aug 2017 13:44:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkwB3-00085U-7L for emacs-devel@gnu.org; Thu, 24 Aug 2017 13:44:22 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:20415) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dkwAx-00080T-IV; Thu, 24 Aug 2017 13:44:15 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7OHiBxa026643 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 17:44:11 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7OHiAsR027472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Aug 2017 17:44:11 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v7OHiAJw014470; Thu, 24 Aug 2017 17:44:10 GMT In-Reply-To: <<83fucg99cj.fsf@gnu.org>> 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: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:217775 Archived-At: > > If the rationale for the decision was only that you want to treat > > package.el as a core part of Emacs rather than as an extension > > then that's a bad rationale. You don't need to turn something on > > just because it is a core part of Emacs. >=20 > I don't really understand what this argument is about. The call to > package-initialize does nothing at all, unless you installed some > packages with package.el. So it is still an opt-in feature, because > the user must decide to install packages for it to do anything. Deciding to "install" a package is somewhat analogous to putting a library in your `load-path'. That doesn't mean it gets loaded. Activating a package (`package-initialize') is somewhat analogous to loading a library. Just because a user has installed a package, it doesn't follow that s?he wants to always and immediately initialize that package for each Emacs session. Your comment is similar to saying that (require 'foo nil t) does nothing if you have not put foo.el in your `load-path', so it wouldn't hurt to automatically load everything that Emacs can find in your `load-path'. Just by putting something in `load-path' you have opted in. To that I say no, and Emacs has always said no. "Installing" a library does not imply that you also want to load/activate it. We separate the two actions on purpose - two levels of opt-in for a library. And we have the same two levels for packages, IIUC. A user might have many libraries in her `load-path', without ever loading some of them in a given Emacs session. A user might have many packages installed, without wanting to activate some of them in a given session. Radon said that the rationale for activating the package system automatically was that "we want to treat package.el as a core part of Emacs rather than an extension." My reply to that was to point out that being part of the core does not imply activating. I said that "lots of things are a core part of Emacs and not extensions, but we don't necessarily turn them on eagerly and by default." Just because something is available by default in Emacs, i.e., without having to "install" it, does not mean that it is (or should be) automatically loaded/activated. Automatic loading/activation at the outset, just because something is available, has not, in the past, been the behavior of "core" Emacs. Core stuff is made available and easy to activate (and yes, some small core set of the core is activated by default), but much of what Emacs makes available to you by default is not activated by default. Radon was saying, I think, that for the package system Emacs dev has decided differently: it has decided that if you have installed a package then you want it activated in all your Emacs sessions (except emacs -Q). He said, I think, that this was decided because opt-in activation was too confusing for some users. But he also said that it was decided because installed packages were to be handled the way Emacs core is handled. It was to that statement that I replied as above: all of Emacs core is not activated by default. Much of it is just made available, for a user to turn on (opt in).