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 17:20:28 +0300 Message-ID: <83tw12cocz.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503238853 21877 195.159.176.226 (20 Aug 2017 14:20:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 14:20:53 +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 16:20:49 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 1djR5m-0004yK-VX for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 16:20:43 +0200 Original-Received: from localhost ([::1]:53487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djR5r-0000iQ-RW for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 10:20:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djR5l-0000hz-2i for emacs-devel@gnu.org; Sun, 20 Aug 2017 10:20:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djR5g-0008BC-4Y for emacs-devel@gnu.org; Sun, 20 Aug 2017 10:20:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djR5g-0008Ap-0W; Sun, 20 Aug 2017 10:20:36 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4125 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1djR5f-0007xI-E6; Sun, 20 Aug 2017 10:20:35 -0400 In-reply-to: (message from Radon Rosborough on Sat, 19 Aug 2017 19:38:05 -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:217630 Archived-At: > From: Radon Rosborough > Date: Sat, 19 Aug 2017 19:38:05 -0700 > > If you object to this proposal, please tell me what the concrete > disadvantages to it would be, or explain why the advantages I have > listed are not valid. Otherwise, let's start the process of figuring > out the best implementation. My take on this, after reading the discussions kindly pointed to by Mark, is that your proposal will replace one problematic situation with another. Whether the new situation will be better than the current one is arguable, but in any case I don't think it will be significantly better. Already a few people said they were unhappy with such a solution. I myself cannot say I like the idea of Emacs creating an init file in the user's home directory. 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. We already do something similar with initializing the frame appearance and its faces. However, such a possibility was not considered, unless I missed something. Admittedly, I know too little about package.el and the related problems, so perhaps what I propose is hard to make work in practice, or it even might be unworkable. However, a couple of people proposed the same idea back when this was discussed, and those people definitely know much more about package.el than I do. So I think we should give this possibility one more chance, and this time we shouldn't reject it unless some serious disadvantages of it are uncovered and described in detail here, so we could all agree they are serious obstacles. Thanks.