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: Wed, 23 Aug 2017 11:00:56 -0700 (PDT) Message-ID: <58ac4c14-3f26-4b21-806a-aa2326ce3d2b@default> References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <2d035e42-006b-e76e-2b3f-75f2dfd87bb7@taydin.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="__1503511257697185739abhmp0009.oracle.com" X-Trace: blaine.gmane.org 1503511346 21848 195.159.176.226 (23 Aug 2017 18:02:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 18:02:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 23 20:02:21 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 1dkZyp-0005A4-Qq for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 20:02:16 +0200 Original-Received: from localhost ([::1]:45088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkZyw-0000Gw-Jo for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 14:02:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkZxj-0000EK-FG for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkZxe-0003U2-JG for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:01:07 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39018) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dkZxe-0003St-6P for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:01:02 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7NI0wqD021445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 18:00:58 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7NI0wKT007278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 18:00:58 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7NI0v5x016922; Wed, 23 Aug 2017 18:00:58 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: userv0022.oracle.com [156.151.31.74] 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:217728 Archived-At: --__1503511257697185739abhmp0009.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The order is: =C2=A0 1. Load package.el init-file 2. Run package-initialize, unless package-enable-at-startup was un-set=C2= =A0in (1) 3. Load regular init-file 4. Nothing else is done afterwards, unlike currently =C2=A0 You just (setq package-enable-at-startup nil) in the secondary init-file, a= nd are never bothered by package.el again.=20 =C2=A0 Again? How about not being bothered the first time? It sounds like `package= -initialize' is evaluated the first time, unconditionally. =C2=A0 And it sounds like, even if I don't use the package system, I will have to = edit a secondary init file (the first one read), just to tell package.el "H= ands off!" And if I want to try a package in a particular Emacs session the= n I need to once again edit that first ("secondary") init file, to enable t= he package system. Is that right? =C2=A0 It's hard to believe this has to be so convoluted. (But I understand that y= ou are saying that what you propose is less convoluted than what we have no= w.) =C2=A0 It seems to me that use of package.el should be just like use of any other = library. Users should explicitly opt in. But I understand that you've said = that it has been decided to enable the package system by default for everyo= ne, at the outset.=20 =C2=A0 That seems like a mistake, to me. And the only argument I have noticed in f= avor of it is that some users make mistakes and get confused. For that, I'd= say start by improving the doc and making things as simple as possible for= them - but without the automatic turn-it-all-on-for-everyone approach. =C2=A0 Users are not idiots. We all make mistakes and get confused. If the doc is = poor and that is a source of confusion then that is the first thing to fix.= If we need to simplify a few things, then it should be done. If it would h= elp to add tutorials or videos then that could be done. =C2=A0 It should not be the end of the world for a user (apparently the typical Em= acs user) to tell Emacs to activate the package system, i.e., opt in. It do= esn't matter, IMO, if 99% of the users want to opt in; it should still be o= pt-in. --__1503511257697185739abhmp0009.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The order is:

 

1. Load package.el init-file

2. Run package-initialize, unless pa= ckage-enable-at-startup was un-set in (1)

3. Load regular init= -file

4. Nothing else is done= afterwards, unlike currently

 

You just (setq package-enable-at-startup nil) in the secondary init-file, and are never bothered by packag= e.el again.

=

 

Again? How about not being bot= hered the first time? It sounds like `package-initialize' is evaluated the = first time, unconditionally.

 

And it= sounds like, even if I don't use the package system, I will have to edit a= secondary init file (the first one read), just to tell package.el "Ha= nds off!" And if I want to try a package in a particular Emacs session= then I need to once again edit that first ("secondary") init fil= e, to enable the package system. Is that right?

 

It's hard to believe this has to be so convoluted. (But I unde= rstand that you are saying that what you propose is less convoluted than wh= at we have now.)

 

It seems to me tha= t use of package.el should be just like use of any other library. Users sho= uld explicitly opt in. But I understand that you've said that it has been d= ecided to enable the package system by default for everyone, at the outset.=

 

That seems like a mistake, to me.= And the only argument I have noticed in favor of it is that some users mak= e mistakes and get confused. For that, I'd say start by improving the doc a= nd making things as simple as possible for them - but without the au= tomatic turn-it-all-on-for-everyone approach.

 

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'>Users are not idiots. We all make mistakes and get confus= ed. If the doc is poor and that is a source of confusion then that is the <= i>first thing to fix. If we need to simplify a few things, then it shou= ld be done. If it would help to add tutorials or videos then that could be = done.

 

It should not be the end of t= he world for a user (apparently the typical Emacs user) to tell Emac= s to activate the package system, i.e., opt in. It doesn't matter, IMO, if = 99% of the users want to opt in; it should still be opt-in.

--__1503511257697185739abhmp0009.oracle.com--