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 11:17:39 -0700 Message-ID: References: <42c93165-2d85-8501-9cc8-99830b7b3646@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114a6a528bf5a105576fbc18" X-Trace: blaine.gmane.org 1503512314 10195 195.159.176.226 (23 Aug 2017 18:18:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 Aug 2017 18:18:34 +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 20:18:28 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 1dkaET-0002Bj-Fu for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 20:18:25 +0200 Original-Received: from localhost ([::1]:45152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkaEZ-0005Yb-VY for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2017 14:18:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkaER-0005YS-7o for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:18:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkaEP-0002s0-P0 for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:18:23 -0400 Original-Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]:37112) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkaEP-0002re-CH for emacs-devel@gnu.org; Wed, 23 Aug 2017 14:18:21 -0400 Original-Received: by mail-lf0-x22f.google.com with SMTP id f7so3940460lfg.4 for ; Wed, 23 Aug 2017 11:18:21 -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=qwxOm48liSfdnYDw6vB886oD8JXZF/CH2+u2Rbzi1h4=; b=HRgQWMbSfi5EE+kB4obs14q1xpGvinIZCM+rsstWhWwS9OoF/+4DWGIHPDliZU0Mam mZruke13+IjRH73/Yc17DoI/Hko0Hz+VtF9B1sGkg6lK39sre8gLQ3whrJPbnMZDVf1e gUfPkM20NJnGXoJ8H6T39soAdqBCmZdiT+QOFEdbYt42NmISgXkx/D6jpoLCkh5Q4hDU NAMaLBZhBhXeVL/Bqdy3yXcrE4qr4cQW+S6VkBt5dLVPm2Q/CiE7QHe9bFbO5S1PY9Tk ySp8uxOJSfFHU9WAOjCmYQE1KM+6BJiv7sIrI2VYoF9PHnFU3HD4IwRZ1HOje20GVVZA yhfg== 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=qwxOm48liSfdnYDw6vB886oD8JXZF/CH2+u2Rbzi1h4=; b=A4sq3x8xoBrL07vHFLIBFKWmYfF+snHmu2GFFkWTkavXFBrvyUQ86fY1L4G7ZPBSZD GyGkL66VMmJ4rBqoNonTYxdEp/eBGRvmdG/6+wpAUnW/vKhTuglWBBNWmwA+dkz+kIcE KLJ3BPBIi4lXfzvJZ03NC12YVT1rYYsc3EX1b5U9/4WDQ9fvP1En1YB74UzdDiOUz2uT bj+mS0taL5TmsEmkCkoYVHaSEAzt9tK7D50vmklBFuhY1tVr6cE1OD4QoMhE/lqw2FPk CxY+Bk2/sgHZmYDOH0MnVkx4/I+xT+Z7teAYNEibTvpYkXJzlSAm6IxPYPjHolBkJ7wo A/CA== X-Gm-Message-State: AHYfb5iRwT6xAh7fE4URQdPvEC+z5M2mRZSoTsDuwx40AP794o60ocrZ HR+p7CK7FBLIhtIPG+6tXvylp9gASw== X-Received: by 10.46.5.67 with SMTP id 64mr1202275ljf.157.1503512299826; Wed, 23 Aug 2017 11:18:19 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Wed, 23 Aug 2017 11:17:39 -0700 (PDT) In-Reply-To: <42c93165-2d85-8501-9cc8-99830b7b3646@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22f 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:217730 Archived-At: --001a114a6a528bf5a105576fbc18 Content-Type: text/plain; charset="UTF-8" > "You tried to call X which is not available and Emacs package > manager was not initialized. I think this proposal is worse than adding a second init-file. Here is why: * It is much more annoying to the user. The second init-file would mean that everything works in all cases with *no* user interaction. Making users deal with pop-up dialogs wastes their time. * The user might well be calling a function that is provided by another package manager, or indeed a manually loaded Lisp library. Emacs can't assume that all undefined functions are the fault of not calling package-initialize; undefined function errors have a scope that is many orders of magnitude greater than the package system. Besides, what about when Emacs is run in batch mode? Then we're back to where we started, since there's no option to prompt for user input. * > w writes (package-initialize) to init) This is bad. We don't want Emacs doing this under any circumstances. Not because it might be annoying (though it is), but because *Emacs usually does it wrong*! If you put `package-initialize' in the init-file, you *must* put it after any package.el configuration, but before any package configuration. This point is impossible to determine in general, especially as it might be elsewhere on the filesystem. * > K would set variable > dear-emacs-i-totally-don-t-need-any-begginers-advice-thanks to t. How? By modifying the init-file? This whole discussion started because we don't want package.el doing that. (Admittedly, this wouldn't be as bad as trying to add `package-initialize' -- but still.) * > I'm not entirely sure on the technical side of catching requires > and void-functions Seems pretty sketchy. You're going to mucking around with one of the most fundamental parts of the Elisp interpreter (namely, function calls) just for the sake of the package manager. Adding a second init-file doesn't require anything this hacky. > Also similar approach is already used in Emacs, there's some key > binding that's disabled until you confirm it in a similar way, sorry > at the moment I don't remember which one. You're thinking of disabled commands. But that's very different: the popup only appears when a user explicitly tries to do something dangerous, rather than during noninteractive execution of arbitrary Lisp code. And furthermore, the disabled-command mechanism serves to prevent users from shooting themselves in the foot; whereas, if Emacs tries and fails to put `package-initialize' in the right place automatically, it is shooting the user in the foot all by itself. > but this seems to be the best solution when all other things are > considered To me, it seems to be worse than the second init-file proposal in every way except that it doesn't require the addition of a second init-file, and that it might have better backwards compatibility. But I am sure there are things I am missing in my analysis; please let me know if this is misguided. --001a114a6a528bf5a105576fbc18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> "You tried to call X which is not avai= lable and Emacs package
> manager was not initialized.

I think this proposal is worse than adding a second init-= file. Here is
why:

* It is much more ann= oying to the user. The second init-file would
=C2=A0 mean that ev= erything works in all cases with *no* user interaction.
=C2=A0 Ma= king users deal with pop-up dialogs wastes their time.

=
* The user might well be calling a function that is provided by
<= div>=C2=A0 another package manager, or indeed a manually loaded Lisp librar= y.
=C2=A0 Emacs can't assume that all undefined functions are= the fault of not
=C2=A0 calling package-initialize; undefined fu= nction errors have a scope
=C2=A0 that is many orders of magnitud= e greater than the package system.

=C2=A0 Besides,= what about when Emacs is run in batch mode? Then we're back
= =C2=A0 to where we started, since there's no option to prompt for user<= /div>
=C2=A0 input.

* > w writes (package-i= nitialize) to init)

=C2=A0 This is bad. We don'= ;t want Emacs doing this under any circumstances.
=C2=A0 Not beca= use it might be annoying (though it is), but because *Emacs
=C2= =A0 usually does it wrong*! If you put `package-initialize' in the
=C2=A0 init-file, you *must* put it after any package.el configuratio= n, but
=C2=A0 before any package configuration. This point is imp= ossible to
=C2=A0 determine in general, especially as it might be= elsewhere on the
=C2=A0 filesystem.

* &= gt; K would set variable
=C2=A0 > dear-emacs-i-totally-don-t-n= eed-any-begginers-advice-thanks to t.

=C2=A0 How? = By modifying the init-file? This whole discussion started
=C2=A0 = because we don't want package.el doing that. (Admittedly, this
=C2=A0 wouldn't be as bad as trying to add `package-initialize' -= - but
=C2=A0 still.)

* > I'm not = entirely sure on the technical side of catching requires
=C2=A0 &= gt; and void-functions

=C2=A0 Seems pretty sketchy= . You're going to mucking around with one of the
=C2=A0 most = fundamental parts of the Elisp interpreter (namely, function
=C2= =A0 calls) just for the sake of the package manager.

=C2=A0 Adding a second init-file doesn't require anything this hacky= .

> Also similar approach is already used in Em= acs, there's some key
> binding that's disabled until = you confirm it in a similar way, sorry
> at the moment I don&#= 39;t remember which one.

You're thinking of di= sabled commands. But that's very different: the
popup only ap= pears when a user explicitly tries to do something
dangerous, rat= her than during noninteractive execution of arbitrary
Lisp code. = And furthermore, the disabled-command mechanism serves to
prevent= users from shooting themselves in the foot; whereas, if Emacs
tr= ies and fails to put `package-initialize' in the right place
= automatically, it is shooting the user in the foot all by itself.

> but this seems to be the best solution when all other = things are
> considered

To me, it see= ms to be worse than the second init-file proposal in
every way ex= cept that it doesn't require the addition of a second
init-fi= le, and that it might have better backwards compatibility. But
I = am sure there are things I am missing in my analysis; please let me
know if this is misguided.

--001a114a6a528bf5a105576fbc18--