[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: shouldn't customize-save-variable raise an error if var is not anopt
From: |
Drew Adams |
Subject: |
RE: shouldn't customize-save-variable raise an error if var is not anoption? |
Date: |
Sun, 31 Dec 2006 12:40:05 -0800 |
> 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.