Demoting `custom-file' to a defvar

Demoting `custom-file' to a defvar

[Artur Malabarba]

2015-11-08 4:33 GMT+00:00 Drew Adams <drew.adams@oracle.com>:
> [There should also perhaps be some mention of the possibly
> confusing fact that `custom-file' is itself a user option,
> i.e., something managed by Customize!  Clearly it is a
> special option, in that you cannot depend on it becoming
> properly defined by loading the file that defines it!]
Thanks for bringing this up Drew.

Honestly, this sounds like a bug to me. Perhaps there's some
witchcraft involved, but I fail to see how it can be possible to save
`custom-file' via the customization interface and have it be properly
loaded on the next session.

Unless someone would like to correct me on that, I'd like to just
demote it to a defvar.

Re: Demoting `custom-file' to a defvar

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> Unless someone would like to correct me on that, I'd like to just
> demote it to a defvar.

I agree with you Artur, it looks like a bug to me too.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

RE: Demoting `custom-file' to a defvar

[Drew Adams]

> 2015-11-08 4:33 GMT+00:00 Drew Adams <drew.adams@oracle.com>:
> > [There should also perhaps be some mention of the possibly
> > confusing fact that `custom-file' is itself a user option,
> > i.e., something managed by Customize!  Clearly it is a
> > special option, in that you cannot depend on it becoming
> > properly defined by loading the file that defines it!]
> Thanks for bringing this up Drew.
> 
> Honestly, this sounds like a bug to me. Perhaps there's some
> witchcraft involved, but I fail to see how it can be possible to save
> `custom-file' via the customization interface and have it be properly
> loaded on the next session.
> 
> Unless someone would like to correct me on that, I'd like to
> just demote it to a defvar.

I don't disagree that it is a gotcha, which is why I mentioned
it.  (And I've mentioned it before.)  I disagree that it should
simply be changed to a defvar.  (But I don't feel strongly about
it.)

Please read the doc string of option `custom-file' carefully.
IMO, users should be able to take advantage of Customize when
defining the value.

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.

The newbie question "Where is my init file?" or "How do I
create my init file?" gets asked over and over anyway, even
though this is covered in node `Init File'.  The same way the
node answers that question, it should show users how to set
and load `custom-file' in their init files.  End of story.

Another thing that could help is for Customize to remind
(nag) you whenever you try to save anything, if `custom-file'
is nil.  The nag should point you to the doc about
`custom-file' in node `Init File'.

An option could turn off this nagging, or a particular
response when nagged could turn it off.  IOW, the nagging
would be for the benefit of newbies, not those who are
aware of `custom-file' but prefer, for whatever reason,
not to use it.

Re: Demoting `custom-file' to a defvar

[bruce.connor.am]

2015-11-08 16:31 GMT+00:00 Drew Adams <drew.adams@oracle.com>:
>> Honestly, this sounds like a bug to me. Perhaps there's some
>> witchcraft involved, but I fail to see how it can be possible to save
>> `custom-file' via the customization interface and have it be properly
>> loaded on the next session.
>>
>> Unless someone would like to correct me on that, I'd like to
>> just demote it to a defvar.
>
> I don't disagree that it is a gotcha, which is why I mentioned
> it.  (And I've mentioned it before.)  I disagree that it should
> simply be changed to a defvar.  (But I don't feel strongly about
> it.)
>
> 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.

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

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

> 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 nodeInit File' we should present a simple init-file
> example that shows how to do this.

Agreed.

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.