From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Wed, 23 Aug 2017 17:44:52 -0700 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> <7acb6970-cbc4-48b2-84c7-afee108d689f@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c14aa30675f21055775253c" X-Trace: blaine.gmane.org 1503535562 13190 195.159.176.226 (24 Aug 2017 00:46:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 00:46:02 +0000 (UTC) Cc: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 02:45:53 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 1dkgHD-0002NM-7A for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 02:45:39 +0200 Original-Received: from localhost ([::1]:46212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkgHJ-0005lo-M2 for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 20:45:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkgHC-0005li-1w for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:45:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkgHA-0007qr-1h for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:45:38 -0400 Original-Received: from mail-lf0-x236.google.com ([2a00:1450:4010:c07::236]:38580) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkgH9-0007pa-Lh for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:45:35 -0400 Original-Received: by mail-lf0-x236.google.com with SMTP id y15so7080268lfd.5 for ; Wed, 23 Aug 2017 17:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ovd5Zr8kf4Q8agW6BfO5iq9OHKEziRy3XK5R4Bf6/fw=; b=F2ECyYQ/bMxBYCbjygnjJpnKke8XgNE2RhpuZsXa3tl3rURJOGg6g/KseYy9SrQZhi pZqO4HjGde8XvutNowlLierDS0yxunDAqztgmRQsUvYk/9XtYbaKeKr4mKQRDGR39OZ5 gYzccEoy3B9/DywgPo249GN19iO2vbNp/685t6F67m3JZgW8DkKZqE8YRaLR9/jjfQwC 1n9fnt/eXyM2XfmnDOJMxWR07nUqVuO2t2wQlPKhLU0wzGyhZOdSZzurUYFfpVtKHe+H FCF0ufjMkdngXvzJmL1hH+BwsVenL/HO6fLnq/BRErRbyVRRJHe1DQB37QMHV8gSqHoy FKEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ovd5Zr8kf4Q8agW6BfO5iq9OHKEziRy3XK5R4Bf6/fw=; b=R+0GESKXRksSwfhwmuBGcmnvjcq8c36e/tgEAWoTxbQr8MvCf2TCWs6LhN+kw3LZGk nnHP6GRD2Y2o5t7ed6ODxT6160ob4nQqR/Q7eeeB3TNdC3pBEZIQkNPHFpLH5gNHby2g FLLYkYqu7nPwJPBK3rqvEf53c4fiWD43aMCNBa0/6XYDxRJUoFC4Ac0G6yexc21yMFsE GIUVKzcpezLjVSyRrNWqb+w41Ld36K+5NbwgA6jhkcMUF9tTmkIeNAu9YjRK7RI7kQ/8 x8oo7jT2FrrxW/NStVlbWYpktqKlvRZxk5ykvSMgkMafXZR7JL8GAID4CNozC5NTKGge MkwA== X-Gm-Message-State: AHYfb5iLDSNVQybvp0tf4RW0DlgdfUM1+moZb2pcUMomndQJRORX6n6c KVpvb2kLu354bmAZW+ast21nI8c2TA== X-Received: by 10.25.59.29 with SMTP id i29mr921464lfa.37.1503535533872; Wed, 23 Aug 2017 17:45:33 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 17:44:52 -0700 (PDT) In-Reply-To: <7acb6970-cbc4-48b2-84c7-afee108d689f@default> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::236 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:217748 Archived-At: --94eb2c14aa30675f21055775253c Content-Type: text/plain; charset="UTF-8" > > And we also expect libraries installed using package.el to work > > similarly to libraries that are shipped with Emacs. > > Dunno what that means. Work similarly how? How could they work > differently? Libraries that are shipped with Emacs are made available automatically without anything needing to be put in the init-file. And this happens during startup, before the init-file is loaded. OTOH, if package.el needs to be set up manually, as you propose, then libraries that are installed using package.el would not be made available automatically unless (package-initialize) was in the user's init-file, and they would not be made available until part-way through the loading of the init-file. Now you may prefer the latter, but you can't argue that it's more consistent behavior. > Why does enabling it by default follow from wanting libraries > installed by it to "work similarly" to libraries shipped with Emacs? Is this clear now? > I still haven't seen an argument why we shouldn't have users opt in > to turn on use of the package system. It's because most people want to use the package system (you admitted this yourself). As you observed, we have a large assortment of tidbits in Emacs core, and whether they are enabled by default depends on whether most users want them enabled by default. > `cua-mode' is not turned on by default. Yet its behavior is used by > 90% of users outside of Emacs. Irrelevant. Most people don't use it *inside* of Emacs, so it's disabled by default. > `delete-selection-mode' is not turned on by default (but it should > be). I'm not saying the decisions about defaults have been made flawlessly. But it's pretty hard to argue that it's more common to want the package manager disabled than it is to want it enabled. Defaults are supposed to eliminate work for the user; what good are they if they don't align with what most people want? > > (setq package-enable-at-startup nil) > > I'll certainly do that. Along with (electric-indent-mode -1). As I'm sure you're aware, you're very much in the minority in both of these things. So you probably shouldn't be surprised that the defaults are not suitable for you. I'm aware that I'm in the minority in using a package manager other than package.el, so I have no qualms with having to override the defaults. > (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 clunky though.) Agreed, it's clunky. But also agreed, it's not a big deal: and considering how many other problems we solve by doing it this way, I think it's a pretty good tradeoff to make. > Why isn't the package-system doc improvement started, as the first > thing to do? Because the current situation (Emacs modifies the user's init-file) is a catastrophe, and fixing that is an ASAP priority. Also, people (e.g. Mark Oteiza) are reluctant to document package.el when the current behavior is clearly broken. > Seems like that would be a good thing for those who are familiar > with the package mgr and are strong proponents of it to work on. I agree but the docs improvements are orthogonal to fixing the code. Indeed, improving the documentation would be our top priority if we were going to disable package.el by default, which is what you want. But we're not going to do that (based on what I've heard from everyone else), so the docs are not necessarily our top priority. > > I'd like us to give more visibility to Emacs packages, because I > > commonly run into people who use package in Atom or Visual Studio > > Code, but not in Emacs (and that's not because Emacs provides the > > corresponding features without an extra packages) > > That is *not* a great reason to enable something by default. Actually, it's a great reason. You know how GitHub is kicking GNU's tail in marketing Atom? Well, "built-in package manager" is literally on the front page of their website, right next to "use productively without ever touching a config file". I'd say this is an indication that people care very much indeed about their text editor coming with a package manager that works right out of the box. > Emacs users know both. No, they don't. At least not the sort of users we want to attract, who don't know anything about Emacs. Yes, all the people on emacs-devel know this stuff, but emacs-devel is about 1% of Emacs users, and about 0.01% of the Emacs users we could have if Emacs worked better out of the box. --94eb2c14aa30675f21055775253c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > And we also expect libraries installed usin= g package.el to work
> > similarly to libraries that are sh= ipped with Emacs.
>
> Dunno what that means. Work= similarly how? How could they work
> differently?
<= br>
Libraries that are shipped with Emacs are made available auto= matically
without anything needing to be put in the init-file. An= d this happens
during startup, before the init-file is loaded.

OTOH, if package.el needs to be set up manually, as = you propose, then
libraries that are installed using package.el w= ould not be made
available automatically unless (package-initiali= ze) was in the user's
init-file, and they would not be made a= vailable until part-way through
the loading of the init-file.

Now you may prefer the latter, but you can't argu= e that it's more
consistent behavior.

> Why does enabling it by default follow from wanting libraries
<= div>> installed by it to "work similarly" to libraries shipped= with Emacs?

Is this clear now?

> I still haven't seen an argument why we shouldn't have = users opt in
> to turn on use of the package system.

It's because most people want to use the package system= (you admitted
this yourself). As you observed, we have a large a= ssortment of tidbits
in Emacs core, and whether they are enabled = by default depends on
whether most users want them enabled by def= ault.

> `cua-mode' is not turned on by defa= ult. Yet its behavior is used by
> 90% of users outside of Ema= cs.

Irrelevant. Most people don't use it *insi= de* of Emacs, so it's
disabled by default.

> `delete-selection-mode' is not turned on by default (but it= should
> be).

I'm not saying the= decisions about defaults have been made flawlessly.
But it's= pretty hard to argue that it's more common to want the
packa= ge manager disabled than it is to want it enabled. Defaults are
s= upposed to eliminate work for the user; what good are they if they
don't align with what most people want?

>= > (setq package-enable-at-startup nil)
>
> I&= #39;ll certainly do that. Along with (electric-indent-mode -1).
<= br>
As I'm sure you're aware, you're very much in the= minority in both of
these things. So you probably shouldn't = be surprised that the defaults
are not suitable for you. I'm = aware that I'm in the minority in using
a package manager oth= er than package.el, so I have no qualms with
having to override t= he defaults.

> (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 clunky though.)

Agreed, it's clun= ky. But also agreed, it's not a big deal: and
considering how= many other problems we solve by doing it this way, I
think it= 9;s a pretty good tradeoff to make.

> Why isn&#= 39;t the package-system doc improvement started, as the first
>= ; thing to do?

Because the current situation (Emac= s modifies the user's init-file) is
a catastrophe, and fixing= that is an ASAP priority. Also, people (e.g.
Mark Oteiza) are re= luctant to document package.el when the current
behavior is clear= ly broken.

> Seems like that would be a good th= ing for those who are familiar
> with the package mgr and are = strong proponents of it to work on.

I agree but th= e docs improvements are orthogonal to fixing the code.
Indeed, im= proving the documentation would be our top priority if we
were go= ing to disable package.el by default, which is what you want.
But= we're not going to do that (based on what I've heard from everyone=
else), so the docs are not necessarily our top priority.

> > I'd like us to give more visibility to Emac= s packages, because I
> > commonly run into people who use = package in Atom or Visual Studio
> > Code, but not in Emacs= (and that's not because Emacs provides the
> > corresp= onding features without an extra packages)
>
> Th= at is *not* a great reason to enable something by default.

Actually, it's a great reason. You know how GitHub is kicking = GNU's
tail in marketing Atom? Well, "built-in package ma= nager" is literally
on the front page of their website, righ= t next to "use productively
without ever touching a config f= ile". I'd say this is an indication
that people care ver= y much indeed about their text editor coming with
a package manag= er that works right out of the box.

> Emacs use= rs know both.

No, they don't. At least not the= sort of users we want to attract, who
don't know anything ab= out Emacs. Yes, all the people on emacs-devel
know this stuff, bu= t emacs-devel is about 1% of Emacs users, and about
0.01% of the = Emacs users we could have if Emacs worked better out of
the box.<= /div>

--94eb2c14aa30675f21055775253c--