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 10:54:30 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83d17qcfa1.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503252123 23117 195.159.176.226 (20 Aug 2017 18:02:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 18:02:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 20:02:00 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 1djUXu-0005iw-SH for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 20:01:59 +0200 Original-Received: from localhost ([::1]:43303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djUY1-0007JG-En for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 14:02:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djURQ-0001ao-3v for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:55:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djURP-00010b-6c for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:55:16 -0400 Original-Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:36224) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djURN-0000zI-Ed; Sun, 20 Aug 2017 13:55:13 -0400 Original-Received: by mail-lf0-x231.google.com with SMTP id f123so9481429lfe.3; Sun, 20 Aug 2017 10:55:13 -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=50cHEGvWhh+EmDsOCg3bKpBlzpdgoqP70ceECYzSACU=; b=cojvPI4kaPC7+K1+fWazyzPtxJCxMSyG45cbhZb5qlKhbeq9zVwAfjeH3dw7Rz9s2r f8h7dE2uHMoqnK9skJt8QuRz4fVlENpWy5pYTyHaAc4quFNuuTGmK6sjSDckzklS5Fn7 a+kaxAeC8fxPNt9ScWBD/SErCSvLG3PioVQj+58QeYL0NYvciyITsBHFWvjxeQxF4CYq HbuM9rHU2JLoKpsD4qHgfI3t6o+Z22gpMdyM8Ssz1s0dfqAE1DSl/1YvDOtab0mw7Vyx e8zyNURzVw+oQNcGUpQOb/wCzhHRmAcwHbBi0yiLSSEZvMPIx9ICg6M2p+WL+AsL2d7m swkg== 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=50cHEGvWhh+EmDsOCg3bKpBlzpdgoqP70ceECYzSACU=; b=tEIk/qS5bABMu0MXddUaQFGmPkFnSBjj6zFyyO3k5BUThSSVe9osXah+lu63SzD5ZL LW0XiwojViS3+7niNjOeza8s0j342YI/tfUExJy28SvMqeX3ZFJizNyMvywz4Jk52OzV 95B2F+qkKybU/Hiq2d5MV+1YYrGxYMqrEj+3Sk9vvkrVmbHvh7C90i4Fd7Vy0WHCyFww bU75El2rJnJfeaQ8fDcrRAoEHr9qZHTUSqfFOqjxZF5yt5TUOdbQUrsp//Vey87Edpj1 F3s2x4lUv2ImsI/o7iVY7PJu4BMgo1aCl/xj4Q2PROEc20PDB3AuBAWDZzRSggwuwzEf c1zQ== X-Gm-Message-State: AHYfb5gO8BkZ339jAHDVMJ2BGLA4OoJt2zK1y2Ctw8HrMulJTNjXwy7P kQf5pAGC5tVAxaSsvKJ5KWICwD79KmFvKMhACQ== X-Received: by 10.46.76.9 with SMTP id z9mr5275202lja.134.1503251711618; Sun, 20 Aug 2017 10:55:11 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Sun, 20 Aug 2017 10:54:30 -0700 (PDT) In-Reply-To: <83d17qcfa1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::231 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:217641 Archived-At: > > > I don't think it will be significantly better. > > > > Can you provide justification for this? Such justification would take > > the form of explaining why the advantages I listed are not valid, or > > there are disadvantages that I missed. > > Both solutions are problematic and cause user annoyance. I don't know > how else to explain that. > > > > I myself cannot say I like the idea of Emacs creating an init file > > > in the user's home directory. > > > > Do you like the idea of Emacs modifying the user's init-file > > automatically, even if it already exists? If not, then do you agree > > that my proposal at least reduces the problem? > > I don't like either of these, but again, I see no significant > improvement, if at all. It would be best to start with explaining in what situation my proposal would cause user annoyance. Explaining specifically why the automatic creation of an init-file is "problematic", apart from the fact that you don't like it, would be a good next step. Even better would be explaining why each of these four specific reasons that my proposal improves on the current situation are invalid: * Emacs does not automatically modify the user's init-file without asking. This eliminates a wide range of unfortunate and annoying side-effects, as you can imagine. Here are two: - People who don't want to use package.el don't get irrelevant and damaging (because of duplicate loading) code stuck in their config. - People who use package.el but call (package-initialize) in some file other than init.el will not get a superfluous call inserted (which might well break their config) if there happens to be an error during init. * In future, if we wish to improve the "out-of-the-box" user experience, we can do so without needing to break backwards compatibility, by simply modifying the template init-file. * It's consistent with standard best practices. All other programs which have a similar problem to package.el solve it by providing a template config file. The reason that all these other programs avoid modifying their config files is the same reason that package.el should avoid modifying the init-file as well. * It will never accidentally place (package-initialize) in the wrong place, which happens frequently with the current system and defeats the entire purpose of an aggressive hack to make things "just work". In fact, the current system *always* places (package-initialize) in the wrong place if the user happened to customize anything like `package-archives' in their init-file (which is extremely common, and I'd go so far as to say that *not* doing this is the uncommon case). > I realize that this is just a repetition of what I said above, but I > don't really understand what needs to be explained here. If this is > still unclear, perhaps you should ask more specific questions. The current (package-initialize) loads the autoload files for all installed packages (or just a subset, if `package-load-list' was modified). It also adds those packages' directories to the load-path. At least this is my understanding. You suggested continuing to do these operations after loading the init-file, but also to > add another call at a proper place in startup.el to do whatever > needs to be done before the user init file is processed. Please explain what exactly needs to be done before the user init-file is processed, and how doing this would allow both package.el configuration and package configuration in the init-file without the prescence of an explicit (package-initialize) call.