From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Tue, 28 Apr 2015 09:25:45 +0900 Message-ID: <877fsxqet2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87383xk4ia.fsf@taylan.uni.cx> <87d22zi69k.fsf@taylan.uni.cx> <87a8xtoq3a.fsf@gmail.com> <87fv7lzl0q.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1430180773 29121 80.91.229.3 (28 Apr 2015 00:26:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 00:26:13 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Thierry Volpiatto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 28 02:26: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 1YmtLf-00081U-Vv for ged-emacs-devel@m.gmane.org; Tue, 28 Apr 2015 02:26:04 +0200 Original-Received: from localhost ([::1]:58189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmtLf-0005tK-BU for ged-emacs-devel@m.gmane.org; Mon, 27 Apr 2015 20:26:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmtLc-0005tD-T9 for emacs-devel@gnu.org; Mon, 27 Apr 2015 20:26:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmtLZ-0000EI-Mw for emacs-devel@gnu.org; Mon, 27 Apr 2015 20:26:00 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmtLZ-00008n-Cv for emacs-devel@gnu.org; Mon, 27 Apr 2015 20:25:57 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 54D3F1C389A; Tue, 28 Apr 2015 09:25:46 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 01C7D1A2CC0; Tue, 28 Apr 2015 09:25:45 +0900 (JST) In-Reply-To: <87fv7lzl0q.fsf@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:185945 Archived-At: Thierry Volpiatto writes: > What is the difference with: > > - (load custom-file) + (load user-init-file) > - loading init file with (load custom-file) on top of it. I don't recall the exact use case for loading custom-file late, I think it was something about using different custom-files on different hosts, but they resided on the same network file system. So the big difference is that if you load before user-init-file, you can't affect what custom-file does in user-init-file. Whereas if you (by default) load late, you can load when you like in user-init-file, and then inhibit the automatic late loading. Such "manual loading" is indeed "advanced" usage in current XEmacs, as it requires knowing exactly how the initialization process works and some of the internals of customize. But the recipe is short. XEmacs has never regretted using custom-file for customizations by default, although the automatic migration process was fraught (since it occurs during initialization, errors in the init file could cause loss of custom code). I do disagree with those who say "don't load custom-file by default". If you think customize sucks, just don't use it, or (in the case of late automatic loading) inhibit loading. Very few XEmacs users ever cared about the details of loading. Few have reported issues due to late loading, but that is probably due to the fact that XEmacs has a protocol ("auto-autoloads.el" and "custom-loads.el") for early initialization of packages. Packages we distribute are strictly vetted for "proper" use of autoload cookies. Specifically, only autoloads of package entry point functions and setting of package flags with properly prefixed names are allowed. This slows initialization in the current implementation (since the autoloads and customization files are per-package), but could be sped up by caching.