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: Fri, 25 Aug 2017 00:14:57 -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 1503634517 19299 195.159.176.226 (25 Aug 2017 04:15:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2017 04:15:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 25 06:15:10 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 1dl61P-0004Nw-Lp for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2017 06:15:03 +0200 Original-Received: from localhost ([::1]:51409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl61W-0007LC-De for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2017 00:15:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl61Q-0007JE-6U for emacs-devel@gnu.org; Fri, 25 Aug 2017 00:15:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dl61N-0002FU-0x for emacs-devel@gnu.org; Fri, 25 Aug 2017 00:15:04 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:52357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dl61M-0002F2-Qs; Fri, 25 Aug 2017 00:15:00 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7P4EwcU024220; Fri, 25 Aug 2017 00:14:58 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id EB4706636A; Fri, 25 Aug 2017 00:14:57 -0400 (EDT) In-Reply-To: (Radon Rosborough's message of "Thu, 24 Aug 2017 18:04:11 -0700") 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 <1760067> : uri <2489372> 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.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:217800 Archived-At: >> 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? > This will introduce performance regressions. Could be. But I think this should only come up in very unusual situations (e.g. when you have lots of packages in ~/.emacs.d/elpa even though you either don't use this directory (and hence set package-user-dir to something else) or you only activate very few of them (by setting package-load-list)). > Besides, having one part of the init process undo a bunch of stuff > that a previous part did seems like a sketchy design to me. Can't disagree that "do+undo" is a poor way to do nothing. > Also, it's impossible for this to work correctly in general since > autoloads can run arbitrary Lisp code. The ability to undo is useful in general. And while it's true that Emacs can't magically know how to deactivate a package, in general, the package can provide extra code that explains how to deactivate itself (e.g. via -unload-function). >> Process ~/.emacs specially so it can start with a special construct >> (with-early-config ...) > That seems like a hacky way to try to combine two files into one file. > Wouldn't it be better to just use two files? I like to keep my config in a single file, and if you want to use a separate file you can do (with-early-config (load "my-other-file")), so while it may be hackish, it's more flexible. BTW, here's another idea: - use a separate "early-config" file. Now, you probably wonder why I say it's "another" idea, so here's the reason: this file would be loaded before the initial GUI frame is created (so it would solve another similar problem at the same time, which is "how do I turn OFF those GUI elements in my .emacs such that they never show up, not even temporarily while we process the .emacs"). With the expected variant: - rather than a separate file, accept a special (with-early-config ...) form at the beginning of the ~/.emacs. Oh wait I already suggested it, but now this should also be used for "config before the initial frame". Stefan