bug#59937: 28.2; Bad defcustom behavior

[Mauro Aranda]

Drew Adams <drew.adams@oracle.com> 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.