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

[Drew Adams]

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

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?

The most inelegant and most confusing is what we have now in GNU Emacs, IMO:
mixing user hand customizations with Customize-generated code in a single
file.

We should move to a system of separate files for user editing and Customize.
That's the first thing to define, including handling these cases:

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

The question of migration is a separate question. We should first define the
desired end state.

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

I should have mentioned only `custom-file'. Variable `user-init-file' is not
a user option, but you can specify the init file using a command-line
option.

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

Please describe the "total automation". But see below; perhaps I've guessed
it sufficiently.

I'm one user who might not benefit from total automation (depending on what
you mean), and I do want to specify my custom file location. (The Emacs
manual, node Saving Customizations, gives an example of why a user might
want to specify it.)

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

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.

> IMO, the unusual case is where custom-file
> exists but the user doesn't want it loaded at normal startup.

I don't disagree with that.

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

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?

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

But why are we talking about this unusual case? Did you think I was
referring to it? When/where would this code be executed? Would it run in
addition to loading the init file or instead of that? Sorry, I don't really
see your point.

>  > Customize should in any case not add (load-file custom-file)
>  > to the init file automatically, except possibly when the init
>  > file is empty. The user might instead have (load-file
>  > custom-file) in some other file (that is loaded) - 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!

I have no idea what you are talking about; sorry. My point was that
Customize should not write (load-file custom-file) to the init file unless
the latter is empty. The reason I gave is that the user might load it from
another file (which is loaded ultimately from the init file).

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

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

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

Then it sounds like we agree. You didn't mention such a hook hack before or
say that the "before" treatment was in fact an "anywhere" treatment. You
mentioned "the `before' option", so I thought the XEmacs startup did
something specifically limited to loading custom file "before" init file.

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

I guess you're saying that a XEmacs user does that to prevent multiple loads
of the custom file (instead of using provide/require or some other way) - is
that right? I have no real problem with that way or another way.

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

I don't see a problem with using `require' and putting a `provide' in the
custom file. But whatever works.

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

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?

I guess you mean the former, but I can't tell. I thought that the "after"
case was loading custom file after init, and that that was the default
behavior ("99%") - so there would be nothing to "insist on". I thought that
you didn't need to do anything to have the custom file loaded after the init
file, and you needed to explicitly load the custom file in your init file to
get it loaded before the (rest of the) init file.

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

I think we agree, but I'm not sure.

I think we're both saying that the custom file would be loaded after the
init file automatically, unless it had already been loaded.

I think you said that XEmacs users could, if they want, have only a custom
file and not an init file, which is something I hadn't considered (it's not
possible in GNU Emacs AFAIK). I assume that that means a custom file at the
default location (or perhaps there is a command-line option also?).

I don't have a problem with that. And I agree that it would be desirable for
a user who doesn't care or want to edit Lisp to be able to simply do nothing
and use only Customize.

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.

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

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

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

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

If you disagree but are otherwise in favor of getting rid of Customize stuff
in the init file, please make a concrete proposal. You have valuable
experience in this area; please contribute a proposal describing the end
result and how to get there.