From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Summary and next steps for (package-initialize) Date: Thu, 24 Aug 2017 13:48:36 -0400 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83wp5xat6i.fsf@gnu.org> <83pobk9aly.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1503596964 17251 195.159.176.226 (24 Aug 2017 17:49:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 17:49:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 19:49:20 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 1dkwFr-0004Eq-Cf for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 19:49:19 +0200 Original-Received: from localhost ([::1]:49708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwFy-0003pl-8C for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 13:49:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwFI-0003pg-8r for emacs-devel@gnu.org; Thu, 24 Aug 2017 13:48:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkwFE-000363-8H for emacs-devel@gnu.org; Thu, 24 Aug 2017 13:48:44 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:49177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwFE-00035d-2W; Thu, 24 Aug 2017 13:48:40 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7OHmaE6015902; Thu, 24 Aug 2017 13:48:36 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 2E906663D3; Thu, 24 Aug 2017 13:48:36 -0400 (EDT) In-Reply-To: <83pobk9aly.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 Aug 2017 19:47:05 +0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6101=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6101> : inlines <6037> : streams <1760006> : uri <2489152> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:217776 Archived-At: >> Calling it before ~/.emacs means that package-initialize is done before >> the user got a chance to configure package.el. So we need'd to provide >> some way to reproduce the behavior you can currently get by setting >> various package.el vars before calling package-initialize. E.g. we >> could let a second call to package-initialize de-activate previously >> activated packages and activate previously not activated packages. > Would a ~/.emacs.d/.package-initialize.el file, to be read by > package-initialize before it does anything else, be a better > alternative for configurations that must be done before > package-initialize is called? To me, it'd be a worst case fallback if we can't find a better solution. > Or maybe you have some other alternative ideas for how to make this > happen? Nothing very concrete yet, no: - Change package-initialize so it keeps track of what it activated and if called a second time, perform a diff between what was activated before and what should be activated now and based on this activate the new pkgs and deactivate the excess ones? - Process ~/.emacs specially so it can start with a special construct (with-early-config ...) I've had other ideas, but they generally suck one way or another. Stefan