From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Sun, 20 Aug 2017 20:36:38 +0300 Message-ID: <83d17qcfa1.fsf@gnu.org> References: <83tw12cocz.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503250656 14432 195.159.176.226 (20 Aug 2017 17:37:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 17:37:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 19:37:31 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 1djUAA-0003C2-AG for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 19:37:26 +0200 Original-Received: from localhost ([::1]:41964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djUAF-0007f7-QZ for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 13:37:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djU9Z-0007dv-AM for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:36:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djU9W-0007Mn-7F for emacs-devel@gnu.org; Sun, 20 Aug 2017 13:36:49 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djU9W-0007Mj-3q; Sun, 20 Aug 2017 13:36:46 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4358 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1djU9V-0004Z2-G5; Sun, 20 Aug 2017 13:36:45 -0400 In-reply-to: (message from Radon Rosborough on Sun, 20 Aug 2017 10:22:20 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:217640 Archived-At: > From: Radon Rosborough > Date: Sun, 20 Aug 2017 10:22:20 -0700 > Cc: emacs-devel@gnu.org > > > Whether the new situation will be better than the current one is > > arguable, > > I've already explained in my email starting this thread why I think > the new situation will be better than the current one. If you > disagree, please tell me why. > > > 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. > > I think we should instead explore the possibility that > > package-initialize will be called only in startup.el. That solution > > came up during the discussions, but AFAICT was dismissed almost > > without any serious consideration. The issues raised against it > > could probably be solved by splitting the package initialization in > > two, one part before, the other after the user's init file is read. > > Can you please elaborate on exactly how this would work, so that we > can make an informed comparison of the advantages and disadvantages of > the proposals? Basically, leave the call to package-initialize in startup.el where it is, and add another call at a proper place in startup.el to do whatever needs to be done before the user init file is processed. That other call could be to a new function, or even to the same package-initialize, if it's feasible to do both parts in the same function (after all, whether the user init file was or wasn't processed is just a simple test away). 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.