RE: always put Customizations in `custom-file', never in `user-init-file'

[Stephen J. Turnbull]

Drew Adams writes:

 > Do you mean an error that pre-exists in the init file or one that is
 > introduced during migration?

Most init files have pre-existing errors if you are trying multiple
Emacsen, all of which load .emacs if it's present.  That was the
common case.

 > If the former, then why would anything be different after the migration?

Our experience was that most people would first encounter migration
around the time of a major release, which is also the time they
typically think about other Emacsen to see what it offers.  This
happened in late beta, where backward incompatibilities (not fboundp,
void-variable, etc) still arise frequently.  The users were aware of
the beta status, but they were still quite shocked that their
customizations were destroyed.

 > Where is [the code that manages loading of `custom-file']? I assume
 > it's not in `user-init-file', since this code loads `user-init-file'.

It requires changing the Emacs startup code.  It needs to be changed
if Emacs wants to do automigration anyway.

 > In any case, IIUYC, users should be able to do whatever they like in the new
 > situation also, because it would only load `custom-file' upon explicit
 > request, never automatically.

Our experience is that there are a lot of users who do fine with *no*
*init file* *at all*.  Use of Customization should not depend on the
presence of an init file, and even one pair of parentheses is enough
to scare some users.  (Cf. "A Brief History of Time".  I don't think
that "(load custom-file)" deserves anywhere near the consideration
that "E = mc^2" got from Prof. Hawking.)

 > Users need to be able to control when Customizations get loaded. I, for
 > example, load `custom-file' last, at the end of my .emacs. Others load it
 > first. Still others load it somewhere in the middle. There should be no
 > automatic loading of `custom-file'.

Our experience says that automatic "after" loading is fine for 99% of
users (that's all we actually provide in a released version), and that
"before" is satisfactory for the rest.  (There may be users we haven't
encountered who *need* finer control, but the fact that in the 7 years
since December 2000 we haven't encountered *one* suggests there are
very few.)  The reason I suggest providing the "before" option is that
I know there are use cases for it.  I have never heard of anybody who
*needed* it loaded in the middle of the init file.  I *have* helped
debug problems that happened because customizations were loaded in the
middle of the init file rather than at the appropriate end, though.