bug#64046: 30.0.50; Quoting in customize choice tags

[Stephen Berman]

On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda <maurooaranda@gmail.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda <maurooaranda@gmail.com>
>  wrote:
[...]
>>> Since there's no problem with widget--simplify-menu, the patch looks
>>> good to me.
>>
>> Thanks.  So Eli, should this go into master, since it's not a
>> regression, or is it ok to install this to the release branch?  It does
>> seem pretty safe, since it's only applying substitute-command-keys in a
>> few more places in widget-choose.
>>
>> Steve Berman
>
> Turns out this code introduces regressions when customizing faces.
>
> With emacs -Q:
> M-x customize-face RET default
> Action the State button and choose: "For All Kinds of Displays"
> Action the Display menu and select "specific display"
> Wrong type argument: number-or-marker-p, "        "
>
> The substitute-command-keys operation is too destructive, and messes
> with things it shouldn't be modifying, like the :offset property of
> widgets in this case.

Sorry for not responding sooner; I was travelling and only now had time
to look into this.  If I debugged it correctly, the problem is that the
value of :extra-offset, 9, satisfies char-or-string-p, so then due to my
patch substitute-command-keys turns it into a string containing a TAB.
The cases intended to be fixed by my patch are where strings with grave
quoting occur, which should be turned into strings with curve quoting.
If so, then testing for stringp suffices, and the attached patch avoids
the regression you found and gives the desired results for the other
cases discussed in this bug.  I don't know why I used char-or-string-p
instead of stringp in my original patch, and don't see a reason for it
now.  Or do you know of cases where testing for stringp is insufficient?

Steve Berman

txtjDtIAqgwET.txt
Description: widget-choose patch