RE: Demoting `custom-file' to a defvar

[Drew Adams]

> > Please read the doc string of option `custom-file' carefully.
> > IMO, users should be able to take advantage of Customize when
> > defining the value.
> 
> Thanks for the pointer, here's the relevant doc part.

Actually, the first sentence is arguably the most important part:

   Please read entire docstring below before setting this through
   Custom.

["Custom" should be "Customize" here and elsewhere in the doc
string, IMO.]

All of the doc string is "relevant" in this discussion, not
just the "relevant part" you quoted.

Here is another important part, for example:

   You can set this option through Custom, if you carefully
   read the last paragraph below.  However, usually it is
   simpler to write something like the following in your init
   file:

IOW, this is an option so that you can take advantage of
Customize, but it is generally simpler to set it in your
init file.  (Taking advantage of Customize includes
type-checking.)

The "last paragraph" is what you quoted:

> > If you save this option using Custom, Custom will write all
> > currently saved customizations, [...] into the file you
> > specify [...].  It will not delete any customizations from
> > the old custom file.  You should do that manually if that
> > is what you want.  You also have to put something like
> > ‘(load "CUSTOM-FILE") in your init file, where CUSTOM-FILE
> > is the actual name of the file.
> 
> So it looks like saving it through customize spares the user the
> trouble of copying over the 2 sexps to the new file. They still have
> to load the new file from their init file, and delete the old sexps.

No, they typically do not need to delete any old sexps.

That was mentioned as a possibility.  Few users will ever do
that, IMO.  This is about copying customizations from one
file (wherever they are currently saved) to another (the
new value of `custom-file').  It's just saying that if the
target file has (like many init files) some non-custom
settings, then it is up to you to do what you want with
those - IOW, using `custom-file' has no bearing on them.

Essentially, this text tries to deal with users who are
used to init files, which can contain anything and
everything, and its message is this: Customize does
nothing with your `custom-file' except manage the Customize
parts of it.  Anything else you might have in there is left
as is.  This is the _same_ message about Customize without
`custom-file': it is how it deals with your init file.

Any text in this doc string about "the old custom file"
could just be removed, IMO, or relegated to the manual.
Especially if we promote the use of `custom-file', so that
user init files are not polluted with Customize stuff
from the outset.

Best practices are for: (1) Customize not to put its stuff
into a file where users have hand-written code and (2) for
users not to add hand-written code to the file where
Customize writes its stuff.

If we get across that message in those terms, then all
mention of "the old custom file" can be removed.

> Sounds like a misfeature, IMO, so I'm still in favor of demoting it
> (though not quite as eagerly as before).

What's the misfeature?  Be specific, please.

> > What's missing is up-front mention of this in the manual,
> > at the place where we explain the init file (node Init File).
> >
> > The general recommendation should be to use `custom-file',
> > and in node Init File' we should present a simple init-file
> > example that shows how to do this.  That's all.
> 
> Agreed.