GNU bug report logs -
#64046
30.0.50; Quoting in customize choice tags
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Tue, 13 Jun 2023 14:04:02 UTC
Severity: normal
Found in version 30.0.50
Done: Stephen Berman <stephen.berman <at> gmx.net>
Bug is archived. No further changes may be made.
Full log
Message #40 received at 64046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda <maurooaranda <at> 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
[Message part 2 (text/x-patch, attachment)]
This bug report was last modified 1 year and 312 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.