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

[Stephen J. Turnbull]

Drew Adams writes:

[XEmacs specific setup omitted]

 > OK, so to have a different custom file from `custom.el' (which is in
 > the same directory as the init file), the user can, in the init file,
 > set `custom-file' to something else - any file, anywhere. Correct?

That is the intent.

 > > The strategy that has been implemented in XEmacs is
 > > 
 > >     1) if there is an init file, load it.
 > >     2) if there is a customizations file, load it.
 > 
 > That sounds good to me.
 > 
 > > If you don't want XEmacs to do that for you (and that is quite
 > > reasonable), simply hide those files by giving them names that XEmacs
 > > doesn't know about.  The only tricky part is getting `custom-file' set
 > > up so that Customize knows where to save its state.
 > 
 > As long as a user who wants to can set `custom-file' to any file name
 > in the init file, I think #1 and #2 should be sufficient.

Plus a mechanism so that the user can control timing if she wants to.
Using `require' to load the custom-file gives that, since an explicit
(provide 'custom-file) will inhibit Emacs, and the user can use load-file.

 > Right, it's not the same behavior as now. That was one of the first
 > things I said: nil would mean there is no custom file - nothing to
 > load and no place to save customizations.

Well, I don't see a good reason for that.  Some people consider
"customizations in .emacs" a feature, and the traditional way to say
that is nil.  Since in the schemes we're discussing now the default
will be non-nil anyway, there's no reason I can see, except to oppress
those folks, to not use a different non-string value to mean "don't
ask, don't tell [the custom-file]".

 > But the XEmacs approach for this sounds OK to me. What happens in
 > XEmacs for saving customizations when the `custom-file' value is a
 > symbol (so no custom file was loaded)? Are settings nevertheless saved
 > to the default custom file?

I don't know; I imagine you get an invalid-state or invalid-argument
error.  The XEmacs design assumes you want to load and save
customizations, and assumes that `custom-file' will be a string;
AFAICS it does not deal gracefully with anything else.  I'm not
advocating the XEmacs design here; I'm just saying it works for us.

 > If so, I think (until I understand better ;-)) that it would be better
 > to prevent saving customizations until the user redefines
 > `custom-file' to a file name (possibly the default file).

Well, an error wil do that.  ;-)

 > if the user's custom file is in a different location and s?he decides
 > not to load it, and then forgets that, then settings get saved to a
 > different custom file (the default), so s?he now has two custom files.

Seems like a YAGNI to me.

> > This is in the context of the code which will try to load custom-file
 > > before the init file, and if not loaded by then, try to load it
 > > afterward.  The idea is that the "before" customization file must have
 > > the default name, or Emacs can't find it.  Then you tell Emacs what
 > > its name is by setq'ing custom-file, and it finds it at the after
 > > stage.
 > 
 > Sorry, now I'm confused again. Are there two different custom files at
 > the same time in this scenario, both a before file and an after file?
 > I don't follow you at all here.

No.  There are use cases for loading before the init file and for
loading after the init file.  This scenario attempts to support both,
without having "(load-file custom-file)" in the init file.  This is a
matter of style, and nobody in Emacs seems to care about it.  So let's
forget about it, and assume that customizations will be loaded after
the init file, unless explicitly loaded or inhibited by the init file.

 > I was thinking this:
 > 
 > To load the custom file before the (rest of the) init file, you would
 > put (load-file custom-file) at the beginning of the init file. You
 > could first set `custom-file' to any file name you wanted.
 > 
 > To load the custom file after the init file, you would do nothing. You
 > could, if you wanted, set `custom-file' in the init file to any file
 > name.

This will work; it's the current state of affairs in released XEmacsen.

 > There would still be the migration to discuss: how to help users move
 > from a .emacs that has Customize stuff to using a separate custom
 > file.

It's not that hard: you find the init file, walk over the top-level
sexps, moving custom-set forms to a new file.  Probably you should
warn but not move any such forms not at top-level.

 > The idea is to prevent someone who doesn't understand well from
 > mistakenly setting `custom-file' to the init file or vice
 > versa. It's about helping users not mistakenly shoot themselves in
 > the foot; it's not about preventing them from aiming at their foot
 > and pulling the trigger.

Naive users are not going to do such things.  It wouldn't occur to
them that it is possible.  Most "modern" applications hide all that
stuff from the user.  Have you ever tried to find your Firefox cache
or bookmarks file?