Re: Documentation for custom-file - is not (load custom-file) needed?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> W.r.t removing custom-file: some users may set custom-file in their .emacs
>> and expect it to do something, so we may as well keep it.

> Sorry, I disagree on this. The only thing I really can think of where
> custom-file is used to do something is in CVS Emacs where custom-file is
> loaded by startup.el if it was not loaded before. I do not think it is any
> big problem if this does not work any more since it is only in CVS. That is
> not to say I do not like the feature, it is just that I believe it would be
> good to get rid of the name custom-file since it could be in
> (custom-set-variables ...) right now and that could cause problems as we
> have seen earlier in this discussion.

I just don't see the benefit in removing it.  If someone set it via
defcustom he's already screwed and none of the changes we plan on making are
going to make things worse for him, AFAICT.

>> After all, when moving the custom file, you need to tell future Emacsen
>> where it'll be, so you need to change your .emacs to either
>> (setq custom-file "newfile") or (load "newfile").  Just M-C-x won't cut it.

> I am not sure about this,

What are you not sure about?  About the need to add/change the `load' or
`setq' statement?  How else do you intend to make future Emacsen aware of
the new location?

> but I can see situations where it would be good if eval set the "custom
> file".

No, I think this would be very wrong.  THE custom file should only be set
by a very explicit user action.  Not just by eval'ing some random expression
that might contain a custom-set-variables.

> Agree, except that I believe we should immidieately also change the name of
> custom-file to something else, perhaps custom-file-in-use (since it is going
> to be set by custom-set-variables).

No: custom-file should not be set by custom-set-variables.  It should only
be set/changed explicitly by a user action.  custom-set-variables should
only record which files call custom-set-variables, to later on help decide
which custom file to use.

Again my sugestion is to (for now) only introduce custom-files and only use
it to double-check the value of custom-file.
In a subsequent step we can change custom-file so that when it is nil, it
means "use the file found in custom-files" (in which case
custom-set-variables would indeed indirectly set the custom file, tho
setting custom-file explicitly would still take precedence, or at least
cause some prompting to occur).

`custom-file' is a user variable and should thus never be changed behind the
user's back.


        Stefan