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

[Luc Teirlinck]

I still do not see any benefit in all this complexity.

What is wrong with:

(setq custom-file ...)
(load ...)

in .emacs? This is what worked in the past and still works now.

The only thing wrong with it that has been pointed out to me are
problems caused by the automatic loading of `custom-file' after
.emacs.  You plan to eliminate that feature (something I agree with),
thereby solving those problems.  The second problem with the current
situation is that customizing through Custom might mislead some users.
You plan to eliminate the defcustom, which solves that problem.  Which
problems are left?

The proposed solution could cause non-trivial trouble for unsuspecting
users, who are in danger of having several files clobbered behind
their back before they notice or understand the problem (see below).

Details:

   2. We should eliminate loading custom-file on startup.
      We should tell users that .emacs should load the appropriate file
      where custom values are stored.

I completely agree that it is better to revert the automatic loading
of custom-file after the loading of .emacs.  This simplifies things
and restores backward compatibility with prior released versions.
Indeed, setting custom-file means only one thing: that the user wants
Custom to write into that file.  If the user wants in addition to load
that file, he can do so.

   1. We should eliminate custom-file as a defcustom.

I do not really disagree with removing the defcustom.  It breaks
backward compatibility to a degree, but on the other hand. it
simplifies things.  It is relatively easy for the user who (like me)
used Custom in the past to adapt.

   3. Calling custom-set-variables in a file should add that file
      to a list of files that have done so.

   4. Evaluating a custom-set-variables call in a buffer should not do
      any such thing.

   5. When saving custom variables, if custom-file is set, save in that file.
      Otherwise, if they have only been loaded from one file, save in that
      file.  Otherwise, if they have been loaded from more than one file,
      save in the most recently loaded such file.

There are (at least) four things wrong with 2-5 above.  Firstly, it
adds complexity for no good reason.  Secondly it breaks backward
compatibility.  Thirdly, it introduces a shaky temporary solution to
something that is currently not really broken and for which we plan to
implement a more solid alternative later on anyway (by 7.). 

Fourthly, and importantly, I believe it is wrong to clobber a user's
file unless the user explicitly asked for Custom to write into that
file by setting custom-file.  People who use outside packages like
initsplit may be in for quite a surprise and a lot of unexpected
trouble with all their customization files getting clobbered one by
one, before they notice the problem.  This is way more serious than
adding a trailing newline.

   6. If the user wants to specify which file to save in,
      he can set custom-file or else just load that file.

These are two different things.  If the user wants to specify which
file to save in, he can set custom-file.  If he wants to load that
file, he can load that file.

   7. Eventually, in the future, we might figure out some clean UI for
      specifying which custom files to use and load under which
      conditions, and for moving definitions between them, but that is
      something for later.

That would require a very careful rewrite of Custom.

Sincerely,

Luc.