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: Sun, 20 Aug 2017 11:39:12 -0700 Message-ID: References: <80273948-1f70-4ec1-abfa-ad0803665c81@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503254407 6486 195.159.176.226 (20 Aug 2017 18:40:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 18:40:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 20:40:03 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 1djV8k-0001Iz-3m for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 20:40:02 +0200 Original-Received: from localhost ([::1]:47540 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djV8p-0003Fj-4Y for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 14:40:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djV8e-0003Dz-Dh for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:39:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djV8d-0008Nx-7n for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:39:56 -0400 Original-Received: from mail-lf0-x22a.google.com ([2a00:1450:4010:c07::22a]:34996) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djV8c-0008NS-Sf for emacs-devel@gnu.org; Sun, 20 Aug 2017 14:39:55 -0400 Original-Received: by mail-lf0-x22a.google.com with SMTP id k186so3330872lfe.2 for ; Sun, 20 Aug 2017 11:39:54 -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=apK/5W9WiXAzt46cTLpmFwHpgYmG5dyOTeEjIECrBpw=; b=Cc5BQWylEzApe5bj0nE5fz/4r8wYEsZe1qs6+snSnCAt6qFR95Rq5OYu9v3qyS7oXo kFOOeu1WdGNDRuxIx6wjHgDwkHAw2aCx9UGFoK1IBf2hsEXQvg8D15rAGheyCQOrszxD E4RYWWXqmYfO5On5BpLUt0JxpZ0ZIf02OvcN+cU47zNmy9qpyIejfcsXldBk4JTuJh8Q wDyU24bS5eYToN099UctoK4cdeGjmM+idWGfVdKWV6A50Vz1ldvnu+SFUD2ri4EqfTBY EXyL4Q59DSdIchl9ptLC1jBgxOY/MRxuH4LYjtRTwLwBJbu/gWKku7/w5xDKcxcCrsYK az9A== 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=apK/5W9WiXAzt46cTLpmFwHpgYmG5dyOTeEjIECrBpw=; b=odrrEbMMm5Y02cBj7KSEzqIG5AB74an/mqNpsZQczOYWI8sjaMAXmIjMcmW/3ppkBZ cAbH0bOsu5SWo57c83zM84PGILN3VJVBzn8HUkZTrNLhmAlyaEnQX3jQz3JjIX4DnTsP 5y13gYnVyj0PMJI5xgsQG2uoyCXKtavkpMU+imTHa2TmRvjumMwNz2fPIDTtM2eeVxXq u+l4tYEPMFBc6YQ/xoo7kq65ffakHvVjQRJO057btvONpDLeL3uTGPgIyY0hlHRaQerc RB76ctEaYCb8Kyr/IaNxWYFMN3YmZWiw8R9ib6SZrDZysDPJ9mKh9SsKNuZMxUJzbIN6 O8QQ== X-Gm-Message-State: AHYfb5je+ZP/hOC46XXEKSVWonhDsAeaufqYcMYkkZ5F2DplQz1S7y7t NbBz1VxmTWti5fsIZ7TIdZN7Y5rlSQ== X-Received: by 10.25.21.94 with SMTP id l91mr1346966lfi.16.1503254393320; Sun, 20 Aug 2017 11:39:53 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Sun, 20 Aug 2017 11:39:12 -0700 (PDT) In-Reply-To: <80273948-1f70-4ec1-abfa-ad0803665c81@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:217643 Archived-At: > So I don't quite follow you there. Let me clarify. I see the following spectrum in this debate: People who want package.el to be enabled by default in spite of the resulting UX problems (too much magic, automatic modification of init-file). ^ | (a) Have Emacs write (package-initialize) into the existing | init-file at startup. | | (b) Have Emacs create a template init-file with | (package-initialize) at startup, if one doesn't exist | already. | | (c) Don't create (package-initialize) calls anywhere, but still | call package-initialize in startup.el. | | (d) Don't call (package-initialize) anywhere; the user must call | it manually in their init-file. v People who want package.el to be disabled by default in spite of the resulting UX problems (package management system doesn't work out of the box). You and I are both at point (d). However, this is a rather extreme position, so I am not arguing for point (d) or even point (c), but rather point (b), because I view point (b) as an improvement over point (a), which is the current situation. Most people on this thread view any solution that doesn't involve package.el working out of the box as a non-starter. That is why I am not proposing such a solution. Instead, I am proposing a solution which has much less potential for annoyance, while still having package.el work out of the box. Does this clear up the confusion? > > I agree wholeheartedly with everything you have said. However, a > > significant number of people on this list disagree, > > Hm. I haven't read this thread very carefully. But I also > haven't gotten the impression that a significant number of > people here have argued for generating init files. You're right. I meant that you're arguing that Emacs shouldn't go through contortions to make package.el work out of the box, and people disagree with that. Meanwhile I'm just trying to make the contortions less horrifying, as an immediate improvement to the current situation. > So I can't say whether your proposal is better or is a compromise of > some sort. The part of my proposal that is relevant to you is the part where Emacs doesn't try to write (package-initialize) into your init-file automatically. Do you consider that an improvement? > I don't like the idea of Emacs generating an init file if there is > none OR of Emacs messing with an existing init file. Same here. Unfortunately, the technical challenges in making package.el work out of the box pretty much guarantee we have to do one of these. Now, whether or not it's worth all this trouble to make package.el work out of the box is another debate, but that's a much harder debate than this one, which is why I'm not arguing it (at least for now). > I don't see your proposal as a "middle way", for users. It's a middle way because creating a default init-file is less intrusive than modifying an existing one, but still more intrusive than doing nothing at all. > Naively, I'd suggest that package.el should do what custom.el > and bookmark.el and lots of other libraries do: Use a separate > Lisp file for persisting info the library needs - a file whose > name/location the user can set using an option. > > If that would mean that a user might need to load that file > at an appropriate place in an init file, so be it. The > package system might well require some understanding of it > before using it. Again, agreed -- but emacs-devel does not want the user to have to have any understanding of the package system before using it, so I'm not making that argument. (By the way, you're spot on with the separate Lisp file idea -- in fact, package.el already does this, and the separate Lisp file [directory] is ~/.emacs.d/elpa. This debate is over how to force users to use package.el by activating it automatically. Again, while neither of us thinks such a thing should be done, I think it's more realistic to try to get it done in the least bad way possible, at least for now.) > FWIW, I am also not in favor of Customize writing to your init file. Same. > If it is difficult for users to find an appropriate place in > their init file to load whatever state/settings file package.el > might require, or to call `package-initialize' or whatever, > then perhaps the package system could be improved to help with > that somehow. The solution here is improving the documentation of package.el, which I've already suggested. > I say "naively" because I know next to nothing about package.el, and > I'm not trying to design the package system. As someone who has in fact already written an Emacs package manager from scratch (straight.el), I think all your points are spot on. Thanks for your comments.