RE: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[Drew Adams]

[Please use plain-text email for the list.]

> Say we go a conservative approach and we only load custom-file automatically 
> if set by the user. We wait to see if people like it and then include a 
> message when custom-file was already loaded by the user. And finally we 
> attempt the 'revolution' setting a default value for custom-file and 
> requiring users to set it to nil if they want the original emacs behaviour.

This is a bit long, but I think it's relatively succinct.

1. Whether to load `custom-file' automatically after the init file is an open 
question.

2. That should never be done if it's already been loaded.  In that case, it's 
clear that the user, one way or another, is controlling when to load it.

3. If, after loading the init file, `custom-file' has not yet been loaded, 
`custom-file' is loaded (automatically).  (Obviously this can only be the case 
when it's not the same file as the init file.) 

#3 is a no-op if the `custom-file' is empty.  If you never use Customize (or 
its functions) to save customize changes - e.g., you use 
`custom(ize)-set-variable(s)' only in your init file etc. - then Customize is 
out of the picture wrt writing.

4. There would be a new variable that you can set or test, which will prevent 
#3: no automatic loading of `custom-file'.  

Why?  Just as you might want to explicitly control where/when, and how many 
times, you load `custom-file', so you might want to prevent loading it 
altogether in some (probably uncommon) situations.

5. `emacs -q' and `emacs -Q' should not load the `custom-file'.  That is, the 
(conditional) automatic loading after the init file should happen only when the 
init file is actually loaded.

In addition, we should add a new switch that suppresses (only) loading of the 
`custom-file', i.e., does the same thing as the variable of #4.  It wouldn't 
prevent loading the init file, and it wouldn't prevent loading `custom-file' 
explicitly from the init file.

6. `custom-file' should have a default value/location. E.g. 

 (defcustom custom-file "~/.emacs-custom.el" ...)

This change would make it so that even _users doing nothing_ get a separate 
`custom-file'.  That's the right thing as the default behavior.

Any users who really want/need to have Customize use their init file would need 
to make a tiny change, yes.

Currently a nil value of `custom-file' has the effect of using the init file.  
That's the situation to be avoided as the default scenario.

We could, however, keep the longstanding nil-means-use-init-file behavior, so 
that if you _explicitly_ set `custom-file' to nil it's the same as setting it 
to the value of `user-init-file'. 

Would that be a good idea?  It's maybe not as clear as explicitly specifying 
the init file location, but it would work.

Explicitly setting to nil means, of course, that users who want to continue 
having Customize use their init file would still need to make a change: set 
`custom-file' to either nil or the init file location.

7. Suppose a longtime user doesn't read the NEWS etc., and _does nothing_.  
What happens then?  Is there a problem?

a. Any `custom*' stuff in the init file is respected when that file is loaded.

b. If the init file doesn't load `custom-file', then it gets loaded 
automatically (from its default location).  If that file doesn't exist, this 
step is a no-op.

c. If the user then makes some custom* changes and saves them, they're saved to 
the default `custom-file' location, _not_ to the init file.

d. In the next Emacs session, steps (a) and (b) are repeated.  This time, the 
`custom-file' exists, so that any saved changes for custom vars and faces are 
respected.

If the init file still contains some custom* setting, it's still respected, 
unless that same var/face was saved to `custom-file' with a different value.  
In effect, `custom-file' settings override any for the same vars/faces in the 
init file.

8. #7 is the case some people have howled about.  Is it really a problem?  It 
could be, in this scenario:

Suppose that at some point in the past you set option `foo' to 10 in your init 
file.  And you later used Customize to change `foo' to 42 and save it (to your 
`custom-file' - the new default behavior).  You might have been thinking that 
Customize was still saving to your init file, replacing that previous setting 
of 10.

Still later (e.g. from habit) you edit your init file, to change the value of 
`foo' from 10 to 314.  Next session, `foo' is 42, not 314 (assuming 
`custom-file' still gets loaded automatically after the init file).

That's what comes from possibly having two locations where you set custom* 
stuff.  At that point (once you figure out what happened), you can do either of 
the following, to get straight:

a. Move your custom* stuff from your init file to your `custom-file' (or just 
delete it from your init file).

From now on, you use only `custom-file' for saving custom* stuff.

b. Set `custom-file' to your init file (or to nil, if we allow that to give the 
same behavior).

From now on, you use only your init file for custom* stuff, just as you did in 
the past.