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:13:49 -0700 Message-ID: References: <42c93165-2d85-8501-9cc8-99830b7b3646@gmail.com> <37bdcd8e-2bb4-fd21-d833-838bd26f5e56@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f17d655954b055774b69b" X-Trace: blaine.gmane.org 1503533709 11898 195.159.176.226 (24 Aug 2017 00:15:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 00:15:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 02:15:04 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 1dkfnY-0002fo-Om for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 02:15:00 +0200 Original-Received: from localhost ([::1]:46149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkfnf-0006uw-5G for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 20:15:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkfn7-0006uN-Ht for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:14:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkfn6-0000F5-67 for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:14:33 -0400 Original-Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:36647) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkfn5-0000EO-QC for emacs-devel@gnu.org; Wed, 23 Aug 2017 20:14:32 -0400 Original-Received: by mail-lf0-x22e.google.com with SMTP id l137so6990716lfg.3 for ; Wed, 23 Aug 2017 17:14:31 -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=DdqorQW4sNGlRiflEanclIsmLnwGRN24F8CIcYigmCU=; b=tO2fe0q7+uNVcUW2SokzhSmGMb/BPUVs7fdgaxi4hAK7Gp2L8RVwKl64UoP30QHNsx rwv1I2UcgAIwbugKv6SNJH4Rs7K/qYnBB2x7mnhvbSN7QX3ZXh/I2xOHI3qWfQptKq6I 2iOb47H/cFIuVguv7Rqe75FvT68JfX9tDKS5x50dNXdUwt/0J3KEQ4i61QRqhl0xXHbr y/rMmDYiAf8HDJiEno3ORlDwtM+7jd0uUHFz9PCFV2OrR4Uvkkjrqs4IhT1msJv0h/OY 7xxhuIEClttv6GvMlLxnicybddWFIqTu1K/Z6vvCBzHMVklJK875dPbnlnicmS/IsW6O iVDQ== 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=DdqorQW4sNGlRiflEanclIsmLnwGRN24F8CIcYigmCU=; b=ZZq5gOGOGVlztdz32PD9oXlgRNgPBQSwUkL60xUY+rPcHuu5uaJZE1vjWrQtLoz5Jr /lYeAGUzoXbGkUYaWASlyBJsglaqN81/3Z030rQqGRqI+fUI7z1Ycpvpw+DZbRIUB0a5 CdkgShjZ+tdKVihAECNPwf5y3OUIxmEqbAO8ydmQSUUNFjRpVhbX8XrmsUEtSAh9FrlC hm59uYrTNJ2ZuschxNCTnJWPrcwFWrix3s0qDs2ufYWKlAFcfrLOarncM2lbrmS7/Bl4 qIHSFMh56zrBeopHUHYtLU5Z3Ijq2ygCEKQ8Ms4ZC65+pI9qptkn8LbjOMb/I55gOThw VY9g== X-Gm-Message-State: AHYfb5iupYjZB2S9lhCal5WM0W8U8Mp3pQekwCcO3iUj+u+j4RIrpDLI 3F53w3sF/UkVlw+hdmw450S6XmCiDUf23fQwhQ== X-Received: by 10.25.21.94 with SMTP id l91mr1414334lfi.16.1503533670436; Wed, 23 Aug 2017 17:14:30 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 17:13:49 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22e 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:217747 Archived-At: --001a113f17d655954b055774b69b Content-Type: text/plain; charset="UTF-8" > we're introducing a major user configuration change Is it really that major to move the place that two options are configured from one file to a different file? To me, this seems pretty trivial. > some shortcoming in Emacs internals I think this assertion requires justification. It's not clear that there is any shortcoming in Emacs internals. On the contrary, I would say that the pattern of configuring a package manager, having it load the packages, and then using the packages is exactly the right pattern to use. > the feature lookup API I proposed in the other letter That proposal requires its own discussion before we decide if it's the right way to go or not. Your argument is only valid if we decide that we want this API, and we haven't decided that yet. > And with the current state of packaging I think such API is almost > inevitable. Whether or not this statement is true will be determined by that discussion. > But with second init, people would still be stuck with those files, > even when raison d'etre for them disappears. "if" raison d'etre for them disappears. We don't know that yet. > 20 years down the line Five years ago, we had no package manager at all. And that's one heck of a breaking change, compared to moving two `setq' declarations from one file to another. > you may need to explain to people "Oh, no, you don't need config.el, > you needed it like 15 years ago, but not anymore" Remember that the only people who are going to be using this secondary init-file are advanced users who want to customize the process of loading packages. IOW, 0.1% of Emacs users, and not the ones we should be concerned about confusing. ~~~~~ But you still haven't addressed the real problem, which is that when Emacs inserts `package-initialize' into the init-file, it usually does so incorrectly. Do you really think that we should adopt a solution which objectively does the wrong thing just for the sake of compatibility with a hypothetical new API whose implementation is likely months or years in the future? In my opinion, this issue is a blocker for your proposal. How are you suggesting to deal with it? --001a113f17d655954b055774b69b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> we're introducing a major use= r configuration change

Is it really that major to = move the place that two options are
configured from one file to a= different file? To me, this seems pretty
trivial.

=
> some shortcoming in Emacs internals

I think this assertion requires justification. It's not clear that
there is any shortcoming in Emacs internals. On the contrary, I wou= ld
say that the pattern of configuring a package manager, having = it load
the packages, and then using the packages is exactly the = right pattern
to use.

> the feature l= ookup API I proposed in the other letter

That prop= osal requires its own discussion before we decide if it's the
right way to go or not. Your argument is only valid if we decide that
we want this API, and we haven't decided that yet.

=
> And with the current state of packaging I think such API is= almost
> inevitable.

Whether or not = this statement is true will be determined by that
discussion.

> But with second init, people would still be stuc= k with those files,
> even when raison d'etre for them dis= appears.

"if" raison d'etre for them= disappears. We don't know that yet.

> 20 y= ears down the line

Five years ago, we had no packa= ge manager at all. And that's one heck
of a breaking change, = compared to moving two `setq' declarations from
one file to a= nother.

> you may need to explain to people &qu= ot;Oh, no, you don't need config.el,
> you needed it like = 15 years ago, but not anymore"

Remember that = the only people who are going to be using this secondary
init-fil= e are advanced users who want to customize the process of
loading= packages. IOW, 0.1% of Emacs users, and not the ones we should
b= e concerned about confusing.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ~~~~~

But you still haven't = addressed the real problem, which is that when
Emacs inserts `pac= kage-initialize' into the init-file, it usually does
so incor= rectly. Do you really think that we should adopt a solution
which= objectively does the wrong thing just for the sake of
compatibil= ity with a hypothetical new API whose implementation is
likely mo= nths or years in the future?

In my opinion, this i= ssue is a blocker for your proposal. How are you
suggesting to de= al with it?

--001a113f17d655954b055774b69b--