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: Friendly discussion about (package-initialize) Date: Wed, 9 Aug 2017 20:32:59 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1502336036 21521 195.159.176.226 (10 Aug 2017 03:33:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Aug 2017 03:33:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 10 05:33: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 1dfeEH-0005CF-QV for ged-emacs-devel@m.gmane.org; Thu, 10 Aug 2017 05:33:50 +0200 Original-Received: from localhost ([::1]:50982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfeEO-00023E-45 for ged-emacs-devel@m.gmane.org; Wed, 09 Aug 2017 23:33:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfeED-000237-NI for emacs-devel@gnu.org; Wed, 09 Aug 2017 23:33:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dfeEB-00037O-Kz for emacs-devel@gnu.org; Wed, 09 Aug 2017 23:33:45 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:35376) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dfeEB-00036V-9U for emacs-devel@gnu.org; Wed, 09 Aug 2017 23:33:43 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id t128so35973201lff.2 for ; Wed, 09 Aug 2017 20:33:41 -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=hN8A0efvl46yN0PT8hBGIBje/XAguQd2EBOuRf3kUUM=; b=SW0EVFkQa9evt0m1mgdz9X7ExZUmmXY/c+x3QA5gsdJdyuQAeCuJYBwPCSwVudLcGU CO4xbzx3nOV5goxBhtL+0EWXyqStFltgS2XQMGf/D5ZEFKRU3oBTNfmuLJQ/gMp7EMyP RR0eHakXdx5v7g+/o5hkAFUNAOQqjVPYD571jHB7YyQF/sYbufjsEPRFhK7Icoj3847r owxX6w9xgMPDH2RXb7SqrrzLLHXJ718TXCvsDceLzbeR9fMGrUlr1m8jilp8VFynmIAt M8CRnzITKMNsWx1KBt3nqKD5ldTMm6EacPEv6qOIcEWR0dk9z14uHW4809I6g97eAdH9 RKew== 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=hN8A0efvl46yN0PT8hBGIBje/XAguQd2EBOuRf3kUUM=; b=nOt9OBhDHGRg2s/flMUY+6E4usMAnQOc2k3AnlNtLibFXBrO4cpui45pVTFC4z9oIv WiSfN4XJMdpdrLB8euTlzlw3BZk496Jh2E5w77JgI6PK/NcBpzcpNH9Z4oQVjrLwRUdK YG0n4in//VTcwWjwMPjWoLn/h98BO5OsFBalv58LnAqJuQLJqk8NjiNZZ3dsTfCS+U7M lKJrEeEveRKFTBGgrFDWqZrEUahz8YXlSsj3z4LExFpERICAb8xmIEzgMblYHDPcruwB rvRyxpXTCAJCdZaEJQOAY4HVJpzex6gp6FGUGIeQaKL2Qoel9lzRsCB90RrYUSguTYBZ YU2Q== X-Gm-Message-State: AHYfb5ixn3nq2XGlVLPj9EJ5wJLRqfXLv58c1H/RQdUBzOYg4RWPstsX DmIdOINMB1dz8Znu9PlvqGGyUI5Htw== X-Received: by 10.25.169.136 with SMTP id s130mr3211242lfe.173.1502336019925; Wed, 09 Aug 2017 20:33:39 -0700 (PDT) Original-Received: by 10.46.64.86 with HTTP; Wed, 9 Aug 2017 20:32:59 -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::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:217387 Archived-At: > > > > The problem is that even if I don't use package.el, there may > > > > be some stuff left in ~/.emacs.d/elpa from previous times. > > > > > > Then don't do that: > > > > I'm actually not sure what "that" is referring to here. > > "That" refers to leaving stuff in ~/.emacs.d/elpa when you're not > using package.el. As an end user, why should I have to know how package.el stores its data in ~/.emacs.d? Isn't that an implementation detail? I'm concerned that knowledge of this information is apparently required to prevent package.el from taking actions all on its own (without being asked) after you've switched to another package manager. At a bare minimum, there needs to be a prominent notice about this in the documentation [1]. But I still maintain that the entire situation is very sketchy. > Maybe we should provide a template init file. I think this is a good idea not just to solve this problem with package.el, but also to make it easier to nudge new users towards Emacs configuration best practices without having to change defaults (which, as we all know, is extremely contentious). > [ This file should be basically empty (tho could contain lots of > comments. ] That can be debated later. At the minimum, though, it would have to contain a (package-initialize), with lots of accompanying comments to explain what it's doing there and where you should put your code to configure packages. > But auto-creating this file just because you start Emacs is also a > problem (similar to the auto-editing of this file you're complaining > about). Agreed. However, it can't possibly be worse that the current situation, right? Currently, a new file is created automatically, *and* any existing one is modified. My proposal would limit this behavior to automatic creation, and not modification. Of course, the init-file shouldn't be created at startup in 'emacs -Q' mode. > We also want to cater to old users of Emacs (who already have their > own ~/.emacs) who start to use package.el. I do like it when things "just work", but there's only so much magic you can do to that end before you start losing things like robustness, predictability, and your sanity. I know I've brought this up before, but can you name a single other program that deals with the problem of bad default behavior by automatically modifying a free-form user-written configuration file on startup, depending on a number of undocumented heuristics? If nobody else does it, I'm sure there's a reason for that. I like to think that most everyone who uses Emacs is intelligent enough to understand a simple concept like "the package manager must be initialized before you can use the packages". The problem is that this simple concept is made quite complicated by all the magic of package.el, and it is not clearly documented at all. If we had better communication with users, then there would be no need for magic. And before you say that some people don't want to modify their init-file, and would prefer to rely on interactive commands only, let me point out that this problem only arises if you try to put package configuration in your init-file. > Which functions do you use accidentally? I didn't mean that I use package.el functions accidentally. I mean that I use package.el functions intentionally (when I am testing other people's package managers, for example), but I accidentally forget to define advices on internal package.el functions before doing so, with the result that my init-file is modified for no reason and I have to go and revert it. > I wonder what you mean by "break". I mean that it inserts a call to `package-initialize' in my init-file when that call is both superfluous and actively harmful due to the particulars of my setup. It objectively does the wrong thing in my case; that is why I said "break". Not to imply that this isn't the right thing to do in general, but it's definitely not always the right thing to do. > > > > > We could change tactic: only call package--ensure-init-file > > > > > when the user installs a package. > > > > > > > > I don't think I would enjoy this either. > > > > > > Do you mean that it would be worse, or that it would be better but > > > still not good enough? > > > > Better but still not good enough. > > Great. Then let's try to do that. I suggest you M-x report-emacs-bug > and request this change Will do, although I'll probably wait to see where this discussion goes first, so I have the proper context. > I don't see why it would have such an effect. Because if we removed `package--ensure-init-file' subsequently, then there would no longer be any automatic activation of packages during init, except for new users who had a template init-file generated. But I'm glad to hear that my concern was unfounded, and the removal of init-file modification via `package--ensure-init-file' will not face any more resistance than it does currently. ===== Something to consider ===== Let's say that one day, another package manager is accepted into Emacs core. Users would have a choice between package.el and alternative.el, whatever the latter may be. Does it still make sense for Emacs to inject a whole bunch of magic into the init sequence, including modifying the user's init-file without their permission under several different conditions, catering specifically to package.el? Should Emacs do this for both package managers? That doesn't make a lot of sense, since of course the packages installed by the two might conflict, and the user only needs one package manager. It's up to the user to explicitly tell Emacs which package manager to use, by placing (package-initialize) or (alternative-initialize) in their init-file. That's the only reasonable solution; anything else is piling hacks on top of hacks. Does this sound familiar? ===== An allegory ===== Let us travel to an alternate universe in which the snippet package YASnippet was designed according to the same principles as package.el, and it was included into Emacs core. What would this mean? Well, firstly, there would be a function called `yas-initialize', and you'd have to call it in order to load all the currently defined snippets, and rebind so that it would expand snippets if appropriate. Whenever you started Emacs, `yas-initialize' would be run automatically, which would rebind without asking you, and then you'd get a comment inserted into your init-file: ;; Added by Yasnippet. This must come before configurations of ;; installed snippets. Don't delete this line. If you don't want it, ;; just comment it out by adding a semicolon to the start of the line. ;; You may delete these explanatory comments. (yas-initialize) You could prevent this by setting the variable `yas-enable-at-startup' to nil, but this wouldn't help you in the case that your init-file encountered an error somewhere, or any number of other interesting edge cases. It would only take one time for that comment to get inserted, and then Yasnippet would start getting activated at startup again, even if you had previously tried to disable it. Of course, being a highly capable Emacs user, you are very careful to never encounter any of those situations... somehow. But one day, you decide to try out Yasnippet, to see if you like it. You set up the configuration just how you like it, in a sub-module of your modularized init-file. But as soon as you load Yasnippet, that comment is back again, and in the wrong place! After an hour or two of poring through the source code, it looks like the only way to permanently disable this behavior is to place an advice on an internal function. You can hardly believe your eyes. "Surely the Emacs developers didn't think that everyone needed Yasnippet activated in just the same way, or even that everyone wants to use Yasnippet, right? This must be a mistake. How could anybody think that globally rebinding on startup is a good idea?" So you go and complain about the situation, only to be told things like: > Well, the rebinding of won't make any difference if the user > doesn't use Yasnippet (i.e., doesn't have any snippets defined). > We want to make it as straightforward as possible for users to > define and use snippets. > People who object to this kind of thing are in the minority; it's > more important to make the experience as seamless as possible for > Yasnippet users. > Just make sure to delete all your snippets whenever you're done > using Yasnippet, that will solve the problem. I'm being intentionally facetious here; I certainly don't intend to give offense. I just think that looking at the situation from outside the lens of package.el will lend some good perspective. After all, no package (and even no package *manager*) other than package.el does this kind of thing, and I've yet to hear a reason why package.el just *has* to be different. Best regards, Radon P.S. If you think that comparing package initialization to rebinding globally is unfair, I'd say on the contrary it's quite an egalitarian comparison: slow init time due to loading unneeded snippets <==> slow init time due to loading duplicate packages conflicts between rebinding and user's bindings <==> conflicts between stale package.el packages and user's packages unpredictable behavior of because installed snippets are not synced between machines <==> unpredictable behavior of Emacs config because installed packages are not synced between machines disrespect of the user's desire to use another snippet manager <==> disrespect of the user's desire to use another package manager P.P.S. I originally started this comparison as a joke, but I'd honestly be less offended by the thing. [1]: https://www.gnu.org/software/emacs/manual/html_node/emacs/Package-Files.html