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 12:38: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="94eb2c184f02d696b7055770de9d" X-Trace: blaine.gmane.org 1503517239 11226 195.159.176.226 (23 Aug 2017 19:40:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 19:40:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 23 21:40:34 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 1dkbVm-00028L-Nt for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 21:40:22 +0200 Original-Received: from localhost ([::1]:45421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkbVt-0008NN-Hg for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 15:40:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkbUz-0008K6-7V for emacs-devel@gnu.org; Wed, 23 Aug 2017 15:39:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkbUx-0000f7-Tt for emacs-devel@gnu.org; Wed, 23 Aug 2017 15:39:33 -0400 Original-Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:34054) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkbUx-0000ei-I6 for emacs-devel@gnu.org; Wed, 23 Aug 2017 15:39:31 -0400 Original-Received: by mail-lf0-x22e.google.com with SMTP id g77so4940613lfg.1 for ; Wed, 23 Aug 2017 12:39: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=ENPBcmTJSvnF6y63M7Jt1g2ZqLbGkwlNQLMp6AFoMsA=; b=DRGxT2TzXKclJbuGUFzSq4gm/UHeFfEi0eL0B37W6TcuE5FzLno5VTtEZQcD3e3dCc 2Az8o3y1E1rciuDv3TEW9KkKuQqRwQkfC87GoNMymtcyqjRe8HjB6xvAV+nTFpjUuXr3 4x1q2//nfndd6hZgcEHHym9TrhMEbT7uG71W6Ilf1swyTofAKacTqm/YSCtDBnB4tUHd HRnUvbDKLWMDTR3cPAW+LbIoCTLeKwx7DfMHKZMjiZumcCIWOwm7sO/ajvFQTK9M0Wcu /DKIIsyHVuxwjBomSyO5PfNsJKMBrGAsdZ7k6CovwEVUQP4tEMprXUIzQSfdze/PcezS /jvA== 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=ENPBcmTJSvnF6y63M7Jt1g2ZqLbGkwlNQLMp6AFoMsA=; b=uAT5LCFSYW2uAs9EnZcEepYj7Aq64fdZnqHtaywvp0qq/xNHVNQTKGaWCMVPKNROKN S21os1I10BX6weDnWB5VRvr6VTK1nFzji81dA3JMn6bzlkfvkwLbchwJJk98aQClxDQ5 0pRL44W69ZwAwmlYnK60bJcKYA+ie/ZH0QQNyxosDoTkun6IfmDQNdzihCdH6R/P127J oToRzZMkSJW8J4woDwtsmvJ8beI2y9ZSt38MSjTBitk45BedDNKnob3Fo/Z85hJE+hO0 dMrLb2zpOMy/rSQpSOAbLeIanKaN9f+QT5GuZVCZcyuUOWCDyZd9V6BWtxwRTaOmO0SW 4hCA== X-Gm-Message-State: AHYfb5hfTXCuX6QNG6YUzy1euSAuV3KecTZKy5yDARFa1pjz0w670Oqd utvnz8s/Xcc2d2yWxlHY02JkLrmY1cM2Q02gEQ== X-Received: by 10.25.219.139 with SMTP id t11mr1202236lfi.256.1503517170109; Wed, 23 Aug 2017 12:39:30 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 12:38:49 -0700 (PDT) In-Reply-To: <37bdcd8e-2bb4-fd21-d833-838bd26f5e56@gmail.com> 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:217734 Archived-At: --94eb2c184f02d696b7055770de9d Content-Type: text/plain; charset="UTF-8" > Yes, it's going to be annoying for two fractions of users, the > targeted fraction - that is the beginners who didn't set up > package.el right and old timers during some rare moments of messing > with their configs. Yes, but the second init-file would result in no annoyance for anyone. Why is a small amount of annoyance better than no annoyance? > And I too would have preferred just removing any additions, but my > proposal seems like an OK compromise. If by "additions" you mean Emacs writing to the init-file, then the second init-file proposal eliminates that behavior entirely. Why is there the need for a compromise? Having Emacs write to the init-file is an order of magnitude more complexity than having an optional second init-file that doesn't need to be used by most people, so it seems to me like any solution that involves Emacs writing to the init-file is a step backwards. > And I don't care about batch mode completely. If you're using batch > mode, than you know what you're doing. Yes, but nobody likes inconsistent behavior. I think the fewer unexpected differences there are between Emacs' modes of operation, the better. > It's just that we can't solve package-initialize by writing to > custom. Correct. And since we can solve package-initialize without writing to anything at all, why not do that? > I'm just proposing to tweak error handling, that's it. You're injecting business logic into an otherwise generic piece of code. I don't think this is a sign of good design. > While you're proposing to add another init file. Can you explain why this is a big problem? In what circumstance would this cause trouble? Maybe it would be better to call it a "config file", because that's basically all it is. And we've got plenty of those already. Dozens, in fact, scattered all over ~/.emacs.d and used by various packages and different parts of Emacs. > we're talking about upgrading experience of a very limited subset of > users The second init-file would accomplish this as well with fewer problems. > (only those new users who haven't yet acquired the skill of > copy-pasting magic spells into their init) The second init-file would not require anybody to do this. In fact, it would free them from such a need, because (package-initialize) no longer needs to be in the init-file. > So, while this is somewhat ambitious, adding another init just for > that is even more so. I think we need to see some concrete disadvantages of the second init-file proposal, since the error-catching proposal has some already. ~~~~~ But really, this is all just an aside. The real problem is that having Emacs add `package-initialize' automatically is *fundamentally broken*. There is NO WAY to determine the correct place to put the call. And having a system that sometimes "fixes" the problem in a way that breaks the user's config can't possibly be better than a system that always works. Right? --94eb2c184f02d696b7055770de9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Yes, it's going to be annoying for two fract= ions of users, the
> targeted fraction - that is the beginners= who didn't set up
> package.el right and old timers durin= g some rare moments of messing
> with their configs.

Yes, but the second init-file would result in no annoyance = for anyone.
Why is a small amount of annoyance better than no ann= oyance?

> And I too would have preferred just r= emoving any additions, but my
> proposal seems like an OK comp= romise.

If by "additions" you mean Emacs= writing to the init-file, then the
second init-file proposal eli= minates that behavior entirely. Why is
there the need for a compr= omise? Having Emacs write to the init-file
is an order of magnitu= de more complexity than having an optional
second init-file that = doesn't need to be used by most people, so it
seems to me lik= e any solution that involves Emacs writing to the
init-file is a = step backwards.

> And I don't care about ba= tch mode completely. If you're using batch
> mode, than yo= u know what you're doing.

Yes, but nobody like= s inconsistent behavior. I think the fewer
unexpected differences= there are between Emacs' modes of operation,
the better.

> It's just that we can't solve package-in= itialize by writing to
> custom.

Corr= ect. And since we can solve package-initialize without writing to
anything at all, why not do that?

> I'm ju= st proposing to tweak error handling, that's it.

You're injecting business logic into an otherwise generic piece of
code. I don't think this is a sign of good design.
<= br>
> While you're proposing to add another init file.

Can you explain why this is a big problem? In what ci= rcumstance would
this cause trouble?

May= be it would be better to call it a "config file", because that= 9;s
basically all it is. And we've got plenty of those alread= y. Dozens, in
fact, scattered all over ~/.emacs.d and used by var= ious packages and
different parts of Emacs.

<= div>> we're talking about upgrading experience of a very limited sub= set of
> users

The second init-file w= ould accomplish this as well with fewer
problems.

<= /div>
> (only those new users who haven't yet acquired the skill= of
> copy-pasting magic spells into their init)
The second init-file would not require anybody to do this. In f= act, it
would free them from such a need, because (package-initia= lize) no
longer needs to be in the init-file.

> So, while this is somewhat ambitious, adding another init just f= or
> that is even more so.

I think we= need to see some concrete disadvantages of the second
init-file = proposal, since the error-catching proposal has some
already.

=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 really, this is all just an aside. The real problem is that hav= ing
Emacs add `package-initialize' automatically is *fundamen= tally
broken*. There is NO WAY to determine the correct place to = put the
call. And having a system that sometimes "fixes"= ; the problem in a way
that breaks the user's config can'= t possibly be better than a system
that always works. Right?

--94eb2c184f02d696b7055770de9d--