GNU bug report logs - #63290
30.0.50; Customize UI shows extra fields for (choice (const ...) (alist ...))

Previous Next

Package: emacs;

Reported by: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>

Date: Fri, 5 May 2023 06:04:01 UTC

Severity: normal

Tags: patch

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 63290 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Cc: 63290 <at> debbugs.gnu.org
Subject: Re: bug#63290: 30.0.50; Customize UI shows extra fields for (choice
 (const ...) (alist ...))
Date: Sun, 16 Jul 2023 10:15:26 -0300
Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:

> This test case shows the issue:
>
> (defcustom test-custom nil "" :type
>   '(choice (alist
>         :key-type (string :tag "key")
>         :value-type (string :tag "value"))
>            (const :tag "auto" nil)))
> (customize-variable 'test-custom)
>
> The UI first shows:
>
> Hide Test Custom: Choice: Value Menu Alist:
> INS
>     State : STANDARD.
>
> Then if I choose "Value Menu", and option 1 to choose the "auto" const
> value, I get:
>
> Hide Test Custom: Choice: Value Menu auto
>     State : EDITED, shown value does not take effect until you set or 
save it.
>
> which is fine.  Then if I choose "Value Menu" again and choose 0 for the
> Alist, I get:
>
> Hide Test Custom: Choice: Value Menu Alist:
> INS DEL key:
>             value:
> INS
>     State : EDITED, shown value does not take effect until you set or 
save it.
>
> I wasn't expecting:
>
> INS DEL key:
>             value:
>
> If I then save the customization, test-custom is ("" . "").  I think it
> should instead be nil.
>

Thanks for the bug report.

>
> It seems like after a const is shown, Customize considers the variable
> "edited".  I don't know why it is adding those extra INS/DEL key/value
> UI boxes though.

The code currently ignores the value if it's present but nil. That's
not good, obviously.  But it might be tricky to fix it because other
widgets depend on the code ignoring it...

I think it might be good to have a different property specify a default
value (defaulting to :value upon creation, if not provided), and let
:value be treated as of today, like the current value holder.





This bug report was last modified 1 year and 330 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.