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 13:27:33 -0700 (PDT) Message-ID: <98f114b6-191e-43f9-b505-9362b9382508@default> References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <2d035e42-006b-e76e-2b3f-75f2dfd87bb7@taydin.org> <58ac4c14-3f26-4b21-806a-aa2326ce3d2b@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="__1503520054743194890abhmp0009.oracle.com" X-Trace: blaine.gmane.org 1503520176 19829 195.159.176.226 (23 Aug 2017 20:29:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 20:29:36 +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 22:29:31 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 1dkcHD-0004Vf-Pw for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 22:29:24 +0200 Original-Received: from localhost ([::1]:45553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkcHK-00081Z-Af for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 16:29:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkcFg-0007TP-Mr for emacs-devel@gnu.org; Wed, 23 Aug 2017 16:27:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkcFY-0007eP-0h for emacs-devel@gnu.org; Wed, 23 Aug 2017 16:27:48 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:23123) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dkcFX-0007dv-Hx for emacs-devel@gnu.org; Wed, 23 Aug 2017 16:27:39 -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 v7NKRaFg029123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 20:27:36 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7NKRZvk001103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Aug 2017 20:27:36 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 v7NKRY9C013817; Wed, 23 Aug 2017 20:27:35 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:217736 Archived-At: --__1503520054743194890abhmp0009.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 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 everyone, at the outset. =C2=A0 The rationale for this decision was that we want to treat package.el as a core part of Emacs rather than as an extension.=20 =C2=A0 Lots of things are a core part of Emacs and not extensions, but we don't ne= cessarily turn them on by default. `cua-mode' is a core part of Emacs, but = it is off by default (good). `delete-selection-mode' is a core part of Emac= s, but is off by default (bad). =C2=A0 We're not talking about whether package.el is core or external (at least I'= m not). And we're not talking about loading package.el by default. We're ta= lking about activating the package system by default. =C2=A0 If the rationale for the decision was only that you want to treat package.e= l as a core part of Emacs rather than as an extension then that's a bad rat= ionale. You don't need to turn something on just because it is a core part = of Emacs. =C2=A0 If you want to debate that, then fine (I might join you), but let's take it= as granted for a moment. If package.el is a core part of Emacs, then we expect all of its features to work by default.=20 =C2=A0 All of `cua-mode' works by default, but it is not turned on by default. =C2=A0 And we also expect libraries installed using package.el to work similarly t= o libraries that are shipped with Emacs.=20 =C2=A0 Dunno what that means. Work similarly how? How could they work differently? =C2=A0 That's why it's enabled by default. =C2=A0 So that's a second rationale. That one is even worse than the "because it's= core" rationale. Nebulous. =C2=A0 Why does enabling it by default follow from wanting libraries installed by = it to "work similarly" to libraries shipped with Emacs? =C2=A0 Note that I'm not really complaining about this decision, even though I don't like package.el and never use it. It seems reasonable to me for the built-in package manager to act like this, even if I don't use said package manager. =C2=A0 I still haven't seen an argument why we shouldn't have users opt in to turn= on use of the package system. Other than the simple observation that some = users have gotten confused about how to appropriately turn it on. =C2=A0 Sounds like the decision amounts to throwing up one's hands and exclaiming = that since some users don't know how to properly turn it on we should just = go ahead and turn it on at the outset for all users. Copout? =C2=A0 > It doesn't matter, IMO, if 99% of the users want to opt in; it > should still be opt-in. =C2=A0 It really depends on whether you view package.el as a core part of Emacs or not.=20 =C2=A0 I don't think so. See above. What does "core part" have to do with it? (And= what does "work similarly" have to do with it?) =C2=A0 After all, the menu and tool bars are turned on by default; VC is turned on= by default (even though lots of people turn it off and use Magit); why sho= uldn't the package manager be turned on by default? =C2=A0 The question is not why shouldn't it. The question is why should it. No goo= d answer, so far. =C2=A0 `cua-mode' is not turned on by default. Yet its behavior is used by 90% of = users outside of Emacs. `delete-selection-mode' is not turned on by default= (but it should be). `transient-mark-mode' was not turned on by default for= decades (it finally was, thank goodness, but only after a lot of time and = debate). And so on.=20 =C2=A0 I think it's fine for stuff to be turned on by default as long as it's easy to turn it off again and swap in something else: =C2=A0 =C2=A0 =C2=A0 =C2=A0(menu-bar-mode -1) =C2=A0 =C2=A0 =C2=A0(tool-bar-mode -1) =C2=A0 =C2=A0 =C2=A0(setq vc-handled-backends nil) =C2=A0 =C2=A0 =C2=A0(setq package-enable-at-startup nil) =C2=A0 I'll certainly do that. Along with (electric-indent-mode -1). =C2=A0 (But apparently I'll need to put the `package-enable-at-startup' setting in= another, "secondary" init file, as an exception. Not a big deal. Kinda clu= nky though.) --__1503520054743194890abhmp0009.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

> It seems to me that use of package.el should be just like use of any<= o:p>

> other library. Users sho= uld explicitly opt in. But I understand that

> you've said that it has been decided to enable the pac= kage system by

> default f= or everyone, at the outset.

<= o:p> 

The rationale for this = decision was that we want to treat package.el

as a core part of Emacs rather than as an extension.

 

Lots of t= hings are a core part of Emacs and not extensions, but we don't necessarily= turn them on by default. `cua-mode' is a core part of Emacs, but it is off= by default (good). `delete-selection-mode' is a core part of Emacs, but is= off by default (bad).

We're not ta= lking about whether package.el is core or external (at least I'm not). And = we're not talking about loading package.el by default. We're talking about = activating the package system by default.

 

If the rationale for the decision was only that you want to t= reat package.el as a core part of Emacs rather than as an extension then th= at's a bad rationale. You don't need to turn something on just because it i= s a core part of Emacs.

 

If you want to debate that, then fine (I might join you), but= let's take it as

=

granted for a moment. If package.el is a core par= t of Emacs, then we

expect al= l of its features to work by default.

 

All of `cua-mode' works by default, but i= t is not turned on by default.

 

And we also expe= ct libraries installed using package.e= l to work similarly to libraries that = are shipped with Emacs.

 

Dunno what that means. Work similarly how? H= ow could they work differently?

<= span style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";colo= r:#244061'> 

That's why it's= enabled by default.

 

So that's a second rationale. That one is even worse than t= he "because it's core" rationale. Nebulous.

=

 

Why does enabling it by default follow from wanting libr= aries installed by it to "work similarly" to libraries shipped wi= th Emacs?

 <= /o:p>

Note that I'm not really complaini= ng about this decision, even though

I don't like package.el and never use it. It seems reasonable to me<= o:p>

for the built-in package mana= ger to act like this, even if I don't use

said package manager.

 

I still= haven't seen an argument why we shouldn't have users opt = in to turn on use of the package system. Other than the simple observat= ion that some users have gotten confused about how to appropriately turn it= on.

 

Sounds like the decision amoun= ts to throwing up one's hands and exclaiming that since some users don't kn= ow how to properly turn it on we should just go ahead and turn it on at the= outset for all users. Copout?

 

> It doesn= 't matter, IMO, if 99% of the users want to opt in; it

=

> should still be opt-in.

=

 

It really depends on whether you view package.el as a core part of=

Emacs or not.

&nbs= p;

I don't think so. See a= bove. What does "core part" have to do with it? (And what does &q= uot;work similarly" have to do with it?)

 

A= fter all, the menu and tool bars are turned on by default; VC is turned on by default (even though lots of people= turn it off and use Magit); why shoul= dn't the package manager be turned on = by default?

 

The question is not why shouldn't it. The question is why should it.= No good answer, so far.

 

`cua-mode' is not turned on by default. Yet its behavior is used by 90% of= users outside of Emacs. `delete-selection-mode' is not turned on by defaul= t (but it should be). `transient-mark-mode' was not turned on by default fo= r decades (it finally was, thank goodness, but only after a lot of t= ime and debate). And so on.

 

I think it's fi= ne for stuff to be turned on by default as long as it's

easy to turn it off again and swap in something = else:

 

     (menu-bar-mode -1)

     (tool-bar-mode = -1)

     (setq= vc-handled-backends nil)

&nb= sp;    (setq package-enable-at-startup nil)

<= div>

 

I'll certainly do that. Along with= (electric-indent-mode -1).

 

(But ap= parently I'll need to put the `package-enable-at-startup' setting in anothe= r, "secondary" init file, as an exception. Not a big deal. Kinda = clunky though.)

--__1503520054743194890abhmp0009.oracle.com--