GNU bug report logs -
#60712
28.2; customize-set-variable won't let you change the type of a choice
Previous Next
Full log
Message #8 received at 60712 <at> debbugs.gnu.org (full text, mbox):
Omar Antolín Camarena <omar.antolin <at> gmail.com> writes:
> If you declare a user option as follows:
>
> (defcustom bool-or-alist '((a . 4) (b . 7))
> "A made up option to illustrate a problem."
> :type '(choice boolean (alist :key-type symbol :value-type integer)))
>
> And then run M-x customize-set-variable to change the value to t the
> change fails with the message:
>
> widget-prompt-value: Value does not match alist type
I didn't manage to reproduce it with this recipe. What I had to do
was, after emacs -Q:
(defcustom bool-or-alist '((a . 4) (b . 7))
"A made up option to illustrate a problem."
:type '(choice boolean (alist :key-type symbol :value-type integer)))
M-x customize-set-variable RET bool-or-alist
I get a prompt:
[boolean] [choice] Set customized value for bool-or-ailst to true:
If I answer y or n, there's no problem, bool-or-alist will be t or nil.
M-x customize-set-variable RET bool-or-alist
New prompt:
[alist] [choice] Set customized value for bool-or-alist to:
Here if you answer t, you get the message:
widget-prompt-value: Value does not match alist type
Which is not surprising, since t is not an alist and the prompt says its
expecting an alist.
What's surprising is that the prompt is choosing one of the two options
beforehand. I mean, going back to the original definition and
re-evaluating, say that I want to use customize-set-variable to change
the alist. I can't do that right away: I have to set it to t or nil,
and then execute customize-set-variable again to set it to an alist.
Not good.
> I think the problem is that widget-choice-prompt-value figures which
> branch of the choice the variable currenty has and then expects the new
> type to be the same.
> If you tag everything, then customize-set-variable works just fine:
>
> (defcustom bool-or-alist '((a . 4) (b . 7))
> "A made up option to illustrate a problem."
> :type '(choice (const :tag "Yes" t)
> (const :tag "No" nil)
> (alist :tag "An alist"
> :key-type symbol :value-type integer)))
>
Yes, but it's not because of the tags. It's just that previously the
choice widget had two choice, and now it has three, and since there's at
least two options to pick (excluding the current),
widget-choice-prompt-value won't choose for you one of the options
beforehand.
We have this condition in widget-choice-prompt-value:
((and (= (length args) 2)
(memq old args))
(if (eq old (nth 0 args))
(nth 1 args)
(nth 0 args)))
ARGS holds the choices available in the choice widget and OLD has
the choice that matches the current value of the choice widget, before
the user enters a new one. This branch has been in the code since like
forever, but I can't explain why it's good to have it.
This bug report was last modified 1 year and 303 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.