[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64046: 30.0.50; Quoting in customize choice tags
From: |
Mauro Aranda |
Subject: |
bug#64046: 30.0.50; Quoting in customize choice tags |
Date: |
Mon, 21 Aug 2023 11:51:36 -0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
Ola x Nilsson <ola.x.nilsson@axis.com> writes:
> On Thu, Jul 20 2023, Stephen Berman wrote:
>
>> On Thu, 20 Jul 2023 16:11:33 -0300 Mauro Aranda
>> <maurooaranda@gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda
<maurooaranda@gmail.com>
>>> wrote:
>>>>
>>>>> 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.
>>>
>>> No trouble at all. And yes, that sounds correct to me.
>>>
>>>> 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?
>>>
>>> I don't know, but I feel like stringp should suffice. So please
install
>>> your fix, and I will be alert if something else breaks.
>>
>> Thanks, pushed to master as commit c55e67081e9.
>>
>> Steve Berman
>
> [Resending as the bug was archived]
>
> I think I ran into another problem with the change.
> Using the simple item definitions (described in the docstring), this
> call
>
> (widget-choose "Title" '(("Option1" . "Foo") ("Option 2" . "Bar")))
>
> will fail with
>
> (wrong-type-argument (listp "Foo"))
Thanks for reporting this.
> Or did I misunderstand how that mode works?
I think your recipe should work, and it worked before.
Hopefully Stephen can take a look at it.
- bug#64046: 30.0.50; Quoting in customize choice tags, Ola x Nilsson, 2023/08/21
- bug#64046: 30.0.50; Quoting in customize choice tags,
Mauro Aranda <=
- bug#64046: 30.0.50; Quoting in customize choice tags, Stephen Berman, 2023/08/24
- bug#64046: 30.0.50; Quoting in customize choice tags, Stephen Berman, 2023/08/24
- bug#64046: 30.0.50; Quoting in customize choice tags, Mauro Aranda, 2023/08/24
- bug#64046: 30.0.50; Quoting in customize choice tags, Stephen Berman, 2023/08/24
- bug#64046: 30.0.50; Quoting in customize choice tags, Mauro Aranda, 2023/08/24
- bug#64046: 30.0.50; Quoting in customize choice tags, Ola x Nilsson, 2023/08/25
- bug#64046: 30.0.50; Quoting in customize choice tags, Stephen Berman, 2023/08/25
- bug#64046: 30.0.50; Quoting in customize choice tags, Ola x Nilsson, 2023/08/28
- bug#64046: 30.0.50; Quoting in customize choice tags, Stephen Berman, 2023/08/28
- bug#64046: 30.0.50; Quoting in customize choice tags, Mauro Aranda, 2023/08/30