Subject: Re: bug#59937: 28.2; Bad defcustom behavior

From: Mauro Aranda <[email-masked]>
Date: Sat, 10 Dec 2022 07:05:11 -0300

Drew Adams <[email-masked]> writes:

 > These first four defcustoms behave as I expect.
 >
 > The first has a default value of nil - empty alist.  The second has a
 > default value of (("key1" :x ("a" "b") ("q"))).  The third had a default
 > value of (("key1" :x () :w ("q"))) - one of the plist-entry values is
 > empty.  The fourth has a default value of (("key1")) - empty plist.
 >
 > The option should be an alist with elements that have a string key and a
 > plist value.  Each plist element has a keyword key and a list of string
 > values.  The alist can be empty, any plist can be empty, and any
 > plist-entry value can be empty.
 >
 > ;; OK
 > (defcustom myvar ()
 >   "..."
 >   :group 'emacs
 >   :type '(alist :key-type (string :tag "Alist key (string):")
 >             :value-type
 >         (plist :key-type symbol
 >                        :options (:x :y :z)
 >                        :value-type (repeat string))))
 >
 > ;; OK
 > (defcustom myvar '(("key1" :x ("a" "b") :w ("q")))
 >   "..."
 >   :group 'emacs
 >   :type '(alist :key-type (string :tag "Alist key (string):")
 >             :value-type
 >         (plist :key-type
 >                        (restricted-sexp :match-alternatives (keywordp)
 >                                         :tag "Plist key (keyword)")
 >                        :options (:x :y :z)
 >                        :value-type (repeat string))))
 >
 > ;; OK
 > (defcustom myvar '(("key1" :x () :w ("q")))
 >   "..."
 >   :group 'emacs
 >   :type '(alist :key-type (string :tag "Alist key (string):")
 >             :value-type
 >         (plist :key-type
 >                        (restricted-sexp :match-alternatives (keywordp)
 >                                         :tag "Plist key (keyword)")
 >                        :options (:x :y :z)
 >                        :value-type (repeat string))))
 >
 > ;; OK
 > (defcustom myvar '(("key1"))
 >   "..."
 >   :group 'emacs
 >   :type '(alist :key-type (string :tag "Alist key (string):")
 >             :value-type
 >         (plist :key-type
 >                        (restricted-sexp :match-alternatives (keywordp)
 >                                         :tag "Plist key (keyword)")
 >                        :options (:x :y :z)
 >                        :value-type (repeat string))))
 >
 > The first OK example specifies the type of the plist key as just symbol,
 > not as keywordp.  But I want to constrain it to be a symbol that's a
 > keyword.  The problem occurs when I try to do that AND I use a default
 > value of nil (see next).

The moment you add a match alternative that won't match the default
value of a restricted-sexp widget (which is nil), then you should change
the default value for the restricted-sexp widget.

 > This one is no good - that's the bug:
 >
 > ;; When click initial INS get prompted for a Lisp expression, get 
warnings,
 > ;; and Customize buffer contents are changed to just INS DEL while 
prompting.
 > ;;
 > (defcustom myvar ()
 >   "..."
 >   :group 'emacs
 >   :type '(alist :key-type (string :tag "Alist key (string):")
 >             :value-type
 >         (plist :key-type
 >                        (restricted-sexp :match-alternatives (keywordp)
 >                                         :tag "Plist key (keyword)")
 >                        :options (:x :y :z)
 >                        :value-type (repeat string))))
 >
 > In this case the default value is nil, but the defcustom also specifies
 > the type of plist values as keywordp.  I think this definition should
 > work fine.

You're looking at a different default value.  The warning comes from Widget,
and says that the default value for the restricted-sexp widget is not
correct.  It's not talking about the default value for the user option.

 > But when you click the sole INS button at the outset you're
 > prompted for a Lisp expression and you simultaneously get a warning that
 > a plist key is not of the right type.  If you enter a Lisp expression
 > (e.g. just 42 or whatever) then the Customize buffer appears as it
 > should.  I think (1) you shouldn't be prompted for anything and (2) you
 > shouln't get any warning of anything.

Examples 2-4 get the same warning once the user clicks the INS button.
If you specify a valid default value for the restricted-sexp widget,
then the warning is gone.

See also bugs #15689, #25152.