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: Thu, 24 Aug 2017 18:03:53 -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> <94a03c4b-a18b-4d54-b662-33cda133edeb@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f17d641e29f05578987a3" X-Trace: blaine.gmane.org 1503623103 669 195.159.176.226 (25 Aug 2017 01:05:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2017 01:05:03 +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 Fri Aug 25 03:04:52 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 1dl33C-0007f9-Pk for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2017 03:04:43 +0200 Original-Received: from localhost ([::1]:51007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl33J-0001xG-5c for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 21:04:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl338-0001wx-QW for emacs-devel@gnu.org; Thu, 24 Aug 2017 21:04:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dl336-0007SH-Oh for emacs-devel@gnu.org; Thu, 24 Aug 2017 21:04:38 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:34510) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dl336-0007S5-Bc for emacs-devel@gnu.org; Thu, 24 Aug 2017 21:04:36 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id d17so4325224lfe.1 for ; Thu, 24 Aug 2017 18:04:36 -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=yZLdPeIWM/Ibu9t5Q1/QeYeGPpUnRXkNwxzMWWzxGQQ=; b=AQ4gIsUUMIAD/MSVocX1G4dc8ClRpxlXAgFf9nrYD88VV9gzl+XOTC1JiiLHBM8ktq YruLrjK9HDczpbwP0tBNBYl5KVH5uj0aGy3pBcemm7Albo2SEc0UEwHSTxLsSDpOEhr8 2IwgBKACz91iOHmjVdK3RyxSwpuDjiOwVIExFgGrLU81WLK0N9FC2u/7UU8stnjZQwS8 4BaB9gpRoNqpKE7vcjh/LRI/S6jmaK4HsvgCAby/vVE7rQCNv/yEjVpBYPkpBQYq5rjw DLY2knsiJ603BONWEChnucticX6mBJHH2cx1nfUQHalErgWUgU0DOGDCB0RmRH3wIT4+ Xp6Q== 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=yZLdPeIWM/Ibu9t5Q1/QeYeGPpUnRXkNwxzMWWzxGQQ=; b=GZC+CGBhIpxl7B5MS7iI1buJ3gKGxQLQj+b59ZTOA8PzSEyj3m8ltvU7uRattul2NH cC0ANcqiuL3BMdZbp7kScHbYG72N2igqFGjwfAr3y0pdspFIzGDTv8qPXZcrG7id3U/r FgQIGJhs5tzNGQ4yiGeu8AQ6avWAjFrgPXD68Bq40t1BhcQ/zNwXF6SdFCn7Cb85/rvT 9byyQwUuzewDWoGfvQP2Y4YwX2sopsMWlPWLiUzbQ11Km1pvSmqSXy6ivzun4rXoLU+a Rhx+Kq/ET4/r7brgfiChOxDr/m+8RogMZX8LvcsSX/06wv9b+0MGA6grqJNF1w7IJqnD BTtA== X-Gm-Message-State: AHYfb5jHbI0hxgiz9p/tdOFqdwYkKtf6dKO/RVL3qrl1w23WKbJMAwB5 8fU0DKyEoBvQtVN9UhSbF6NPQQMBVg== X-Received: by 10.25.21.94 with SMTP id l91mr2643688lfi.16.1503623074929; Thu, 24 Aug 2017 18:04:34 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Thu, 24 Aug 2017 18:03:53 -0700 (PDT) In-Reply-To: <94a03c4b-a18b-4d54-b662-33cda133edeb@default> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22a 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:217791 Archived-At: --001a113f17d641e29f05578987a3 Content-Type: text/plain; charset="UTF-8" Drew, Some of this is a little redundant because it's already been said by other people. Sorry about that. > > 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. > > Yes, just by putting them in (the default value of) `load-path' - > no? That's not all that the pkg mgr does, IIUC. If it were then I > guess we wouldn't be having this discussion. You are wrong. Libraries that are shipped with Emacs are put in the load path and have their autoloads evaluated, and this is exactly what the package manager does to activate a third-party package -- nothing more, nothing less. In particular, the package manager *certainly* does not actually load any features; that would be unacceptable. > My naive preference is not to have a `package-initialize' and so not > to have to worry about where it is placed or when it is evaluated. What? How would package code get added to the load path, then? Would users do that manually? That would defeat the entire purpose of package.el, namely to add package code to the load path for you. Honestly, I think the package.el-config-file proposal gets the closest to your desired situation, by making it so that `package-initialize' need not be called from your code, and you do not have to think about where to place it. > No one has shown that most users want wrt automatic pkg-mgt > enabling, afaik. That's because most of us consider it common knowledge. I challenge you to either (1) find somebody else here who thinks that this statement is false, or (2) suggest a practical way we could test its validity. > > 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. > > [...] > > But all of that is, I think, irrelevant, or at least I don't see the > relation. Because most users want to use a package manager, it should be enabled by default. That is my argument, and that is why what I said is relevant. It is irrelevant whether the default enable/disable state of other Emacs features has been decided correctly. > I can't judge whether you are right about how many other problems > your proposal will solve. Eli, at least, has proposed exactly the same as what I'm suggesting, and had this to say about the package.el-specific config file: the problem we are solving with this file is a much larger one, and affects many more users [than the problem of dealing with a new config file]. > > Because the current situation (Emacs modifies the user's > > init-file) is a catastrophe, and fixing that is an ASAP priority. > > Was it considered so before you proposed your proposal? Yes. See https://www.reddit.com/r/emacs/comments/56fvgd for example. > I too don't like the idea of Emacs modifying user init files. But > we've lived with that for at least as long as we've had Customize - > many, many years. Customize never modified the init-file automatically, without asking. > How dire is the situation wrt the pkg system, realistically? It's impossible to answer this objectively. But the current situation reflects a horrible design flaw, and I think it's important that core Emacs code reflects good design. I think everyone else here agrees with me there, although we may all have different opinions on what that good design should be. > I'm questioning whether a good dose of better doc etc. wouldn't go a > long way, and wondering why there isn't a first emphasis on that: > getting out the good word to those who are confused about the simple > need to call `package-initialize' (somewhere, at least). Because we could make it so that `package-initialize' doesn't need to be called at all, and then such documentation would be superfluous. Two birds with one stone. > But it seems to work well enough that zillions of users make good > use of it everyday. Same for Microsoft Windows XP, which currently runs on about 140 million computers worldwide. The size of the userbase is irrelevant to design questions. > Do you really think that most pkg users who have problems have the > more complex kinds of problems for which your proposal is intended? Why do you say my proposal is intended to solve "complex kinds of problems"? It is intended to solve the problem of people forgetting to put `package-initialize' in their init-files, which as you mentioned is the #1 most common problem people have with package.el. Sure, the current situation also solves that problem. But it goes about it in the wrong way, and introduces a number of silly negative side-effects. > I don't see zillions of questions about it. > > I do see some, which often boil down to this answer: call > `package-initialize'. Well, we could solve all of those questions in one fell swoop with the package.el-specific config file, by eliminating the need to call `package-initialize'. > It's a shame that someone might take the point of view that because > the pkg system has some problems they wouldn't want to bother to > document it better. That smells a bit like a copout. Sorry, but I feel the same way as Mark (and I know for a fact that there are a fair few other users who concur, but are too burnt out to comment here; see the Reddit thread I linked). If I tried to write documentation for package.el, it would go like: In your init-file, you must call `package-initialize', which shouldn't be necessary but is due to design flaws. As a hacky workaround to fixing the underlying problem, Emacs will add this function call to your init-file automatically if it is absent. However, note that it usually does so incorrectly, and you will have to fix it by hand. > > 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. > > It could reasonably be an immediate priority whether or not the pkg > system is disabled by default. Fine. But as I said, that discussion is orthogonal to this one. Better documentation is not a substitute for good design, nor does the converse hold. > > 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. > > (Do ours care enough to improve the docs and usability?) I've written more than 40 emails here in an attempt to improve the usability. Because this effort is time-consuming, I'm focusing on one and only one thing: improving the usability. Not improving the docs, even though I also think the docs should be improved. --001a113f17d641e29f05578987a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Drew,

Some of this is a litt= le redundant because it's already been said by
other people. = Sorry about that.

> > Libraries that are shi= pped with Emacs are made available automatically
> > withou= t anything needing to be put in the init-file. And this happens
&= gt; > during startup, before the init-file is loaded.
>
> Yes, just by putting them in (the default value of) `load-path&= #39; -
> no? That's not all that the pkg mgr does, IIUC. I= f it were then I
> guess we wouldn't be having this discus= sion.

You are wrong. Libraries that are shipped wi= th Emacs are put in the
load path and have their autoloads evalua= ted, and this is exactly what
the package manager does to activat= e a third-party package -- nothing
more, nothing less.
=
In particular, the package manager *certainly* does not actu= ally load
any features; that would be unacceptable.
> My naive preference is not to have a `package-initialize&#= 39; and so not
> to have to worry about where it is placed or = when it is evaluated.

What? How would package code= get added to the load path, then? Would
users do that manually? = That would defeat the entire purpose of
package.el, namely to add= package code to the load path for you.

Honestly, = I think the package.el-config-file proposal gets the closest
to y= our desired situation, by making it so that `package-initialize'
<= div>need not be called from your code, and you do not have to think about
where to place it.

> No one has shown = that most users want wrt automatic pkg-mgt
> enabling, afaik.<= /div>

That's because most of us consider it common k= nowledge. I challenge
you to either (1) find somebody else here w= ho thinks that this
statement is false, or (2) suggest a practica= l way we could test its
validity.

> &= gt; As you observed, we have a large assortment of tidbits in Emacs
> > core, and whether they are enabled by default depends on wheth= er
> > most users want them enabled by default.
&= gt;
> [...]
>
> But all of that is, = I think, irrelevant, or at least I don't see the
> relatio= n.

Because most users want to use a package manage= r, it should be enabled
by default. That is my argument, and that= is why what I said is
relevant. It is irrelevant whether the def= ault enable/disable state of
other Emacs features has been decide= d correctly.

> I can't judge whether you ar= e right about how many other problems
> your proposal will sol= ve.

Eli, at least, has proposed exactly the same a= s what I'm suggesting,
and had this to say about the package.= el-specific config file:

=C2=A0 =C2=A0 the problem= we are solving with this file is a much larger one,
=C2=A0 =C2= =A0 and affects many more users [than the problem of dealing with a
=C2=A0 =C2=A0 new config file].

> > Becau= se the current situation (Emacs modifies the user's
> >= init-file) is a catastrophe, and fixing that is an ASAP priority.
>
> Was it considered so before you proposed your proposa= l?


> I too don't like the idea of Em= acs modifying user init files. But
> we've lived with that= for at least as long as we've had Customize -
> many, man= y years.

Customize never modified the init-file au= tomatically, without asking.

> How dire is the = situation wrt the pkg system, realistically?

It= 9;s impossible to answer this objectively. But the current situation
<= div>reflects a horrible design flaw, and I think it's important that co= re
Emacs code reflects good design. I think everyone else here ag= rees
with me there, although we may all have different opinions o= n what
that good design should be.

> = I'm questioning whether a good dose of better doc etc. wouldn't go = a
> long way, and wondering why there isn't a first emphas= is on that:
> getting out the good word to those who are confu= sed about the simple
> need to call `package-initialize' (= somewhere, at least).

Because we could make it so = that `package-initialize' doesn't need to
be called at al= l, and then such documentation would be superfluous.
Two birds wi= th one stone.

> But it seems to work well enoug= h that zillions of users make good
> use of it everyday.
=

Same for Microsoft Windows XP, which currently runs on = about 140
million computers worldwide. The size of the userbase i= s irrelevant to
design questions.

> D= o you really think that most pkg users who have problems have the
> more complex kinds of problems for which your proposal is intended?

Why do you say my proposal is intended to solve &qu= ot;complex kinds of
problems"? It is intended to solve the p= roblem of people forgetting to
put `package-initialize' in th= eir init-files, which as you mentioned
is the #1 most common prob= lem people have with package.el.

Sure, the current= situation also solves that problem. But it goes
about it in the = wrong way, and introduces a number of silly negative
side-effects= .

> I don't see zillions of questions about= it.
>
> I do see some, which often boil down to = this answer: call
> `package-initialize'.

Well, we could solve all of those questions in one fell swoop with= the
package.el-specific config file, by eliminating the need to = call
`package-initialize'.

> It&#= 39;s a shame that someone might take the point of view that because
> the pkg system has some problems they wouldn't want to bother t= o
> document it better. That smells a bit like a copout.
=

Sorry, but I feel the same way as Mark (and I know for = a fact that
there are a fair few other users who concur, but are = too burnt out to
comment here; see the Reddit thread I linked). I= f I tried to write
documentation for package.el, it would go like= :

=C2=A0 =C2=A0 In your init-file, you must call `= package-initialize', which
=C2=A0 =C2=A0 shouldn't be nec= essary but is due to design flaws. As a hacky
=C2=A0 =C2=A0 worka= round to fixing the underlying problem, Emacs will add this
=C2= =A0 =C2=A0 function call to your init-file automatically if it is absent.
=C2=A0 =C2=A0 However, note that it usually does so incorrectly, a= nd you will
=C2=A0 =C2=A0 have to fix it by hand.

<= /div>
> > I agree but the docs improvements are orthogonal to fix= ing the
> > code. Indeed, improving the documentation would= be our top
> > priority if we were going to disable packag= e.el by default, which
> > is what you want.
>=
> It could reasonably be an immediate priority whether or not= the pkg
> system is disabled by default.

=
Fine. But as I said, that discussion is orthogonal to this one. Better=
documentation is not a substitute for good design, nor does the<= /div>
converse hold.

> > I'd say thi= s is an indication that people care very much indeed
> > ab= out their text editor coming with a package manager that works
&g= t; > right out of the box.
>
> (Do ours care e= nough to improve the docs and usability?)

I've= written more than 40 emails here in an attempt to improve the
us= ability. Because this effort is time-consuming, I'm focusing on one
and only one thing: improving the usability. Not improving the docs,=
even though I also think the docs should be improved.
=
--001a113f17d641e29f05578987a3--