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

[Drew Adams]

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

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?

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

No, you're the one who brought up not loading the custom file, not
I.  I agreed with you that that is a corner case.

I used almost the same words as Lennart. I did not use the words you
(mis)quote at all. I said:

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

It's true that initially my idea was not to load custom-file
automatically but only when the user explicitly loads it. But I then
agreed that it could be loaded automatically after the emacs
file. Provided it has not already been loaded.

It's that last proviso that I insisted on, to prevent reloading.
That's all.  I never mentioned the case that you brought up and that
"you keep focusing on", which is a user who exceptionally wants to
prevent loading custom-file for some reason.

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

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

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. (You could define
`custom-file' to non-nil during a session, to be able to save.)

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?

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

Again, this is about the unusual case where some user wants to prevent
loading an existing custom file for some reason. I think it would be
bad to go ahead and save to the default custom file - better to let
the user know that s?he needs to specify the custom file. Otherwise,
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.
 
>  > 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.

I think we basically agree on what's needed.

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

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.

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

Initially set to the default, which is a file name, not nil: OK.

If a user sets it to nil, I was saying that should prevent use of a
custom file. But you suggested using a non-nil symbol to do that
instead, which is fine.

You're saying that nil would give the current GNU Emacs behavior: save
to .emacs. Probably a good idea. Any "retro `everything in .emacs'
types" would appreciate that.

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.

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

The idea is not to try to prevent someone who is bent on saving
Customize stuff to .emacs from doing it. Your nil `custom-file'
suggestion explicitly allows that. 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.

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

Good. I don't see any important differences between what you and I
have each suggested.

A couple of others have disagreed, without much in the way of argument
against. Stefan doesn't see the need for a change. Bob sometimes wants
to edit Customize stuff in a single file and doesn't want to remember
two file names.

Let's see what others think. If we can agree about what is TRT, then
we can think about how to handle migration. That could range from (1)
just informing people of new behavior to (2) helping them make some
init-file changes.

For those users who have no custom file now, the minimum for #2 could
be to tell them they can set `custom-file' to nil in .emacs if they
really want to keep Customize settings there.

However, we will need to think about the common case where a user will
do nothing, including not read the doc. We don't want a user to end up
with old Customize stuff in .emacs and new Customize stuff in a
custom-file.