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

[Stephen J. Turnbull]

Drew Adams writes:

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

IIRC, in XEmacs, that was false: if you had no .emacs and tried to
save, Customize would create it for you.  (Presumably after prompting.)

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

Inelegant, and confusing to the user.

 > And we should give the user a chance to specify the files to use
 > for `user-init-file' and `custom-file'.

The kind of user who benefits from total automation doesn't *want*
that, and the kind of user who doesn't benefit doesn't *need* that.

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

What do you have against customizations, that you're willing to go to
such lengths that nobody will ever accidently have their
customizations loaded?  IMO, the unusual case is where custom-file
exists but the user doesn't want it loaded at normal startup.  I think
it's perfectly reasonable to have such users set custom-file to a
non-nil symbol and have Emacs compute

    (progn
      (setq custom-file (or custom-file user-init-file))
      (when (and (stringp custom-file)
                 (file-readable-p custom-file))
        (load custom-file)))

where it loads the custom-file.  This is backwards compatible with the
current meaning of nil, and allows users to suppress loading of the
Customizations.

 > Customize should not assume anything about where/when
 > `custom-file' is loaded.

I don't understand.  Customize is about providing a hood-welded-shut
facility for customizations.  Warranty is void if this seal is broken.
ALL FACES YOURS NOW OURS ARE.

This is not a problem.  setq works on defcustoms, you know!

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

*shrug* It's theirs for the taking.  The same after-init-hook hack
that currently allows the "before" users to put (load custom-file) at
the very top of their user-init-file allows them to put it anywhere
else they want, too.

;;; load custom.el here, not after the init file
(load custom-file)
(setq custom-file-saved custom-file
      custom-file nil)
(add-hook 'after-init-hook (lambda () (setq custom-file custom-file-saved)))

Of course the hacker who writes the support for automatic "after"
loading needs to ensure that after-init-hook is called *after*
custom-file would be loaded.

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

No.  As you note, such an option would need to be a command-line
option.  Rather, people who insist on "after" would rename their
custom-file---I used "~/.xemacs/after-init.el" when I was
experimenting---and put something like

(setq custom-file (expand-file-name "after-init.el" "~/.xemacs"))

in their user-init-file.  This is preferable to automatic "after"
loading primarily because using after-init-hook looks more fragile,
and this has more robust failure modes (the custom.el-was-loaded flag
is managed by Emacs transparently to the user, so custom.el won't be
loaded twice unless the user does it explicitly).

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

"Option overload" is not a good thing.  Users who want to take the
flexibility can do so using standard functionality.  Other users just
don't want to know, and I don't blame them. ;-)