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

[Drew Adams]

>  > 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.

Not sure I understand.

Currently, if a user doesn't have an init file, then s?he can use Customize
but s?he cannot save Customize customizations. That would not change with
what I propose.

And if s?he doesn't try to save Customize customizations, then she still
need not have an init file.

If a user wants to save Customize customizations, then s?he will need both
files in my proposal, whereas s?he currently needs only an init file.

We should, in any case, make it easy for a user, after using Customize (but
not being able to save, because no files), to create an init file that
contains (load-file custom-file) - but see also below. And we should give
the user a chance to specify the files to use for `user-init-file' and
`custom-file'.

>  > 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

I suppose that we could adopt the convention that if `custom-file' was not
loaded by the init file (or by any files it loaded), but variable
`custom-file' is defined at the end of this loading, then `custom-file'
would be loaded at that time.

Another approach would be to display a warning at the end of init file
loading that `custom-file' was defined but never loaded. That's perhaps a
bit of a cop-out.

Customize should in any case not add (load-file custom-file) to the init
file automatically, except possibly when the init file is empty. The user
might instead have (load-file custom-file) in some other file (that is
loaded) - Customize should not assume anything about where/when
`custom-file' is loaded.

> (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.)

That sounds about right to me. But there is no reason not to give users the
flexibility to control when `custom-file' is loaded, is there?

> 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.

Again, that all sounds right to me.

Are you suggesting having an explicit option for this, with `before' and
`after' values? That has the advantage that it obviates needing to put
(load-file custom-file) in the init file.

On the other hand, it loses some flexibility - you might want to load
`custom-file' after some event, or in some situation but not in others, or
after loading some feature, or...  Granted, it might be that few users would
need or want that flexibility, but why not allow it?

A better possibility would be to have option values `before', `after', and
nil, with the latter meaning no automatic loading - the user could still use
an explicit (load-file custom-file).

Of course, there might be a problem for Emacs to try to know the value of
that option without having yet loaded `custom-file'... ;-) Back to editing
the init file, no? Or to having Customize put something in the init file to
say when `custom-file' should be loaded... Neither of which would help those
users you mention who want saved customizations but no init file.

Overall, I think (so far) the best solution is for users to put (load-file
custom-file) in their init files, and to help them do that when they first
try to save Customize settings, and to help them migrate from an existing
init file that contains Customize settings.

At the end of the day, in my view, a user would have either no init file and
no custom file or both. And the init file would contain (load-file
custom-file) somewhere (with a comment), or else the custom file would not
get loaded (or it could be loaded at init end, as mentioned above).

BTW, it might also be worth putting something at the beginning of the custom
file to detect its being loaded more than once - perhaps raise an error in
that case.