emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59937: closed (28.2; Bad defcustom behavior)


From: GNU bug Tracking System
Subject: bug#59937: closed (28.2; Bad defcustom behavior)
Date: Sat, 22 Jul 2023 12:57:02 +0000

Your message dated Sat, 22 Jul 2023 15:56:37 +0300
with message-id <83lef885q2.fsf@gnu.org>
and subject line Re: bug#59937: 28.2; Bad defcustom behavior
has caused the debbugs.gnu.org bug report #59937,
regarding 28.2; Bad defcustom behavior
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
59937: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59937
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.2; Bad defcustom behavior Date: Sat, 10 Dec 2022 05:06:56 +0000
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).

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.  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.

  Warning (widget-bad-default-value): 
  A widget of type restricted-sexp has a bad default value.
  value: nil
  match function: widget-restricted-sexp-match
  match-alternatives: (keywordp) Disable showing Disable logging

See attached screenshot, which shows the prompt as well as the
Customize buffer during prompting and the *Warnings* buffer.

In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.2251)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Attachment: throw-emacs-defcustom-bug.png
Description: throw-emacs-defcustom-bug.png


--- End Message ---
--- Begin Message --- Subject: Re: bug#59937: 28.2; Bad defcustom behavior Date: Sat, 22 Jul 2023 15:56:37 +0300
> Cc: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 16 Jul 2023 20:00:40 -0300
> From: Mauro Aranda <maurooaranda@gmail.com>
> 
> I'm sorry it took me so long to actually take a look at this.  I had to
> reread the conversation to put myself back into topic.
> 
> As I said in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59937#26
> I was looking for a way to:
> 1. Being able to create the restricted-sexp widget, even if the default
> value for it isn't valid.
> 2. Being able to do it without prompting the user.
> 
> That's what the attached patch does.  AFAIU, we both agreed that that
> approach was a good enough fix for this bug, so that the behavior of
> certain defcustoms is less confusing.  We didn't really agree back then
> about the warning, and I'm guessing that we still disagree on that, so I
> didn't change anything about the warning.

Thanks, installed on the master branch, and closing the bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]