Re: Calling (package-initialize) sooner during initialization

[Stephen J. Turnbull]

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.