bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64046: 30.0.50; Quoting in customize choice tags


From: Ola x Nilsson
Subject: bug#64046: 30.0.50; Quoting in customize choice tags
Date: Mon, 21 Aug 2023 14:04:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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"))

Or did I misunderstand how that mode works?

/Ola





reply via email to

[Prev in Thread] Current Thread [Next in Thread]