RE: shouldn't customize-save-variable raise an error if var is not anoption?

[Drew Adams]

>     I don't know the answer, because I don't know if
>     `customize-save-variable' is intended to "work" by program on
>     variables that have not yet been declared using defcustom.
>     I can't find any doc that speaks to this.
>
> I don't know.  However, given that `customize-variable' will operate
> (if you force it to) on a variable defined thus
>
>     (defvar foo45 nil "*Foo you")
>
> and does allow saving a value for that variable, I guess it is
> reasonable that `customize-save-variable' also allows that variable.

I wasn't aware that `customize-option' would do that. What you say makes
sense, in that case.

I have always thought that there are user options, which are customizable
variables, defined by defcustom, and there are additional, non-option (i.e.
not customizable) variables that you can set via `set-variable' but you
cannot customize: those whose doc strings start with *. I expected that both
`customize-option' and `customize-save-variable' would be reserved for
options, that is, for variables that are in fact customizable (using
Customize), and I didn't think that applied to all variables whose doc
string begins with *.

I think that the fact that you can customize all variables that you can set
with set-variable must be new with Emacs 22.

> I do not see any bugs in what you described.

I was afraid that the option created might not be a full-fledged option, and
that that might lead to some problems (unknown to me) down the road. I guess
that your "do not see any bugs" reply means that there is nothing to worry
about?

>     The effect seems to be, in fact, to create an option, just as if
>     defcustom had been used. I am not sure if everything needed is done,
>     however. If not, isn't it misleading for a non-option variable to have
>     values for the properties `saved-value', `variable-comment', and
>     `saved-variable-comment'?  Might some programs that examine such
>     properties not be misled by this? Similarly, does it make sense for
>     the variable to be saved with the value to the user's custom file?
>     Maybe, maybe not, depending on what the design intends, and whether
>     the result of calling `customize-save-variable' is an option in all
>     aspects.