bug#60712: 28.2; customize-set-variable won't let you change the type of a choice

[Mauro Aranda <maurooaranda@gmail.com>]

Omar Antolín Camarena <omar.antolin@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.