From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Sat, 18 Apr 2015 13:16:54 -0400 Message-ID: References: <87383xk4ia.fsf@taylan.uni.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429377436 28223 80.91.229.3 (18 Apr 2015 17:17:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 17:17:16 +0000 (UTC) Cc: =?utf-8?Q?Taylan_Ulrich_Bay=C4=B1rl=C4=B1=2FKammer?= , emacs-devel To: Artur Malabarba Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 18 19:17:06 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YjWMb-0006bP-R1 for ged-emacs-devel@m.gmane.org; Sat, 18 Apr 2015 19:17:05 +0200 Original-Received: from localhost ([::1]:46343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjWMb-0006G2-6G for ged-emacs-devel@m.gmane.org; Sat, 18 Apr 2015 13:17:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjWMY-0006FN-4F for emacs-devel@gnu.org; Sat, 18 Apr 2015 13:17:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjWMU-0002a7-Q8 for emacs-devel@gnu.org; Sat, 18 Apr 2015 13:17:02 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:33840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjWMU-0002Za-Lm for emacs-devel@gnu.org; Sat, 18 Apr 2015 13:16:58 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3IHGs5K031334; Sat, 18 Apr 2015 13:16:55 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B758ACE1; Sat, 18 Apr 2015 13:16:54 -0400 (EDT) In-Reply-To: (Artur Malabarba's message of "Sat, 18 Apr 2015 14:32:34 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 2.2 X-NAI-Spam-Rules: 4 Rules triggered GMAIL_UNAME_2_DOT=1, GMAIL_UNAME_2_DOT_W_NOFROM_SGMAIL=1, NOFROM_SGMAIL=0.2, RV5280=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5280> : inlines <2752> : streams <1424616> : uri <1910000> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185610 Archived-At: I think all those discussions are missing the point. If we want to improve the system to the point of considering adding new init files, then we should try and fix other problems at the same time. So here's one of the larger problems: How can we make the system work such that the user can: - Use customize to set package-user-dir, package-pinned-packages, etc... - Use customize to configure a variable which has a :require which loads a file that's only available after calling package-initialize. The first requires package-initialize to be called late, the second requires package-initialize to be called early. Maybe a solution is to simply make customize-set-variables lazier, so that variables with a :require see their setting delayed to after package-initialize was called. Or else, have package-initialize be called by customize-set-variables. Or... Stefan >>>>> "Artur" == Artur Malabarba writes: >> has it been considered yet to simply support an optional >> >> ~/.emacs.d/pre-package-init.el > Yes. I suggested this on a previous thread (before starting this one) and > someone complained of yet another file affecting emacs behaviour. Then I > suggested the streamlined version of that in the first email of this thread > (having a file that delays initialization, but doesn't actually get > evaluated), and the few responses I got still preferred the other option.