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

[Stephen J. Turnbull]

Drew Adams writes:

 > > Inelegant, and confusing to the user.
 > 
 > How do you do it in XEmacs (after the migration)? I think you said that
 > users can have a custom file without an init file. Where do they let Emacs
 > know what file is their custom file? If they don't set `custom-file' in the
 > init file, where is it set and read at startup?

(defvar user-init-directory (expand-filename "~/.xemacs"))
(defvar user-init-file-basename "init.el")
(defvar custom-file-basename "custom.el")

or similar happen very early in the startup process, even before
options processing.  There's a bunch of compatibility cruft which
checks for ~/.emacs and so on, but the basic idea is that there are
standard places for these.

There are options --user-init-directory (so I can do
--user-init-directory=~drew/.xemacs and get your whole setup) and
--user-init-file (for those with multiple personalities).  Since our
current custom.el policy is load-after-init-file, we don't have a
command option to set that; you have to use a setq on custom-file in
the init file.

 > - a user who starts from scratch and doesn't know or care about Lisp
 > - users who want to specify the location of their custom file
 > - users who want to load the custom file at different times
 >   during startup, via an explicit (load-file custom-file)

All of these are supported by the XEmacs scheme, although the support
for the third could be better.

 > Huh? I don't have anything against customizations. What lengths do you think
 > I'm going to? I don't understand your point here. What is the problem you
 > see with what I suggested? I think it's the same thing Lennart suggested,
 > which you said "certainly works":
 > 
 > >>    1) load .emacs
 > >>    2) if .emacs did not load custom-file then do that
 > >>       immediately after .emacs.

The difference is that you keep focusing on the case where the user
wants to do something complicated, and optimizing for it.  The
presumption throughout has been "Emacs should not load customizations
unless the user says to do so."  This doesn't make a lot of sense IMO.

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.

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.

However, for the customizations file, your suggestion of using `require'
to load it makes a lot of sense; to suppress automatic loading, just do
`(provide 'custom-file)'.  This can be done explicitly to suppress the
customizations entirely, or implicitly in the customizations file as
you suggest.

 > I guess that is some proposed standard startup code (and not user code). I
 > think you're saying that a user who for some reason doesn't want to load an
 > existing custom file would set `custom-file' to a non-nil symbol, say
 > `foobar', to avoid loading it. Is that right?

Yes.

 > I would have said that s?he would just set `custom-file' to nil: if the
 > value doesn't name an existing file, then no custom file gets loaded (in GNU
 > Emacs, but perhaps not in XEmacs).

AIUI, that is not backward compatible: if custom-file is nil,
Customizations currently get saved to the user's init file.  If that's
not true, then setting it to nil is fine.

 > In any case, I think (?) we agree now that Customize need never write
 > (load-file custom-file) to the init file.

It should never do that (except on explicit user request).

 > I guess maybe you're saying that the custom file should always be loaded
 > automatically, after the init file, but I can't tell.

Yes.  As I say, there are use cases for loading it before the init
file, but that can be handled with an explicit load.

 > Again, I personally have no problem with it being loaded automatically at
 > the end, if it has not already been loaded.
 > 
 > To prevent it being loaded more than once, the custom file could have
 > (provide 'custom-file), and the startup sequence could do an implicit
 > (require 'custom-file custom-file) at the end. That way, if it was already
 > loaded (e.g. if a user put (load-file custom-file) at the beginning of
 > .emacs) then it would not be reloaded.

That would work.

 > Sorry, but I'm really having trouble following you. That just sets
 > `custom-file'. How does that change the before/after behavior? And which do
 > you mean here by "insist on `after'"? Do you mean load custom file after
 > init file or load init file after custom file?

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.

 > Is this something you would agree with:
 > 
 > - Customize saves to the location specified by `custom-file' or to a default
 > location if that option is nil.

Sort of.  `custom-file' should be initialized to the default.  The
user can still explicitly set it to nil, and behavior should be
backward compatible.

 > - Customize never writes to the init file. The custom file and the
 > init file cannot be the same file. If the value of `custom-file' is
 > .emacs (or the value of the init file from the command line), then
 > it is ignored (and a warning is shown?).

No.  Having the init file be the customizations file is a very bad
idea IMO, but code that tries to enforce it is a waste of space.
"ln -s .emacs .emacs.customizations", for starters.

 > - A user can prevent loading an existing custom file by either setting
 > `custom-file' to a non-nil symbol (your suggestion) or by using a
 > command-line option.

Yes.  (We've never had a request for such a command-line option.)

 > - At startup, .emacs is loaded, if it exists.

Yes.

 > - After loading .emacs (or instead of loading it, if it does not exist), the
 > custom file is loaded, unless it has already been loaded. If the value of
 > `custom-file' names an existing file (other than the init file), then that
 > is loaded; otherwise, if the default custom file exists, then it is loaded.
 > If the user has no init file, then the custom file must be at the default
 > location.

Yes, except that as above I would not bother with the check for the
init file being different from the customizations file.  Also, I would
initialize `custom-file' to the default, making the "otherwise" clause
unnecessary.