GNU bug report logs - #76181
30.0.93; defcustom is not ordering-agnostic

Previous Next

Full log

View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 76181 <at> debbugs.gnu.org
Subject: bug#76181: 30.0.93; defcustom is not ordering-agnostic
Date: Mon, 10 Feb 2025 14:26:36 -0300

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Mon, 10 Feb 2025 13:19:14 -0300, Mauro Aranda
>> <maurooaranda <at> gmail.com> said:
>
>     Mauro> Robert Pluim <rpluim <at> gmail.com> writes:
>     >> (this is a reduced test case after I noticed
>     >> `org-table-duration-custom-format' behaving funny.)
>     >>
>     >> emacs -Q -nw
>     >> ;; evaluate the following defcustoms
>     >>
>     >> (defcustom this-is-broken 'one
>     >> "user option one"
>     >> :type '(choice
>     >> (symbol :tag "two" two)
>     >> (symbol :tag "one" one)))
>     >>
>     >> (defcustom this-is-ok 'one
>     >> "user option two"
>     >> :type '(choice
>     >> (symbol :tag "one" one)
>     >> (symbol :tag "two" two)))
>     >>
>     >> M-x customize-variable RET this-is-broken RET
>     >>
>     >> ;; The display is wrong, itʼs showing the "two" tag, but the 
correct
>     >> ;; value:
>
>     Mauro> For the 'choice type, manual says:
>
>     Mauro> If some values are covered by more than one of the 
alternatives,
>     Mauro> customize will choose the first alternative that the value 
fits.
>     Mauro> This means you should always list the most specific types 
first,
>     Mauro> and the most general last.
>
> Hmm, ok. Although in this case the types are equally specific.

So, the first one wins.  The :tag is just informative, it has nothing to
do with the symbol widget's value.  And the default value is for
creating it if nothing else is specified.  In this case, there's a
symbol specified, one.

>     Mauro> So this works as expected, a symbol matches a symbol
>     Mauro> widget, no matter
>     Mauro> what the default value for that symbol widget is.
>
>     Mauro> Alternative is to use const.
>
> Yes, that works better. Although if `choice' can figure it out based
> on the values for `const', it should be able to do the same for
> `symbol'. Any pointers to where I should look to fix this?

I don't think there's anything to fix.  What's the point in using two
symbol widgets in a choice? A symbol widget is for the user to enter a
symbol, and it can be done regardless of the tag or its default value.

What you're asking is to match according to the default value, and that
will break a lot of stuff: after editing the widget, the current
value isn't equal to the default value anymore, and that will result in
perfectly valid values being rejected.

Previous Next

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