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 #20 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 15 Jun 2023 13:39:34 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Wed, 14 Jun 2023 17:05:32 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> 0. emacs -Q
>>> 1. Evaluate the following defcustom:
>>> (defcustom my-test "a"
>>> "Test."
>>> :type '(choice (string :tag "Use `a'" "a")
>>> (string :tag "Use `b'" "b")))
>>> 2. M-x customize-option RET my-test RET
>>> 3. In the buffer *Customize Option: My Test* note that in the string
>>> "Use ‘a’" following the "Value Menu" button the quote marks are in
>>> the "curve" style (‘’).
>>> 4. Put point on the "Value Menu" button and type RET.
>>> 5. The buffer " widget-choose" contains these lines:
>>> 0 = Use ‘a’
>>> 1 = Use ‘b’
>>> Note that the quote marks in this buffer are also in the "curve"
>>> style.
>>> 6. With the mouse pointer over the "Value Menu" button press mouse-1,
>>> popping up a menu titled "Choice" containing these items:
>>> Use `a'
>>> Use `b'
>>> Note that the quote marks in this menu are in the "grave" style (`')
>>> instead of the "curve" style.
>>>
>>> The use of the "curve" style in the " widget-choose" buffer is due to
>>> commit bd3b426ebb7a60045839e97c9da9bfd249fab1f1, but that commit did not
>>> take popup menus into account. The attached patch does so. Since the
>>> status quo ante long predates emacs-29 and this is just a stylistic bug,
>>> I made the patch against master.
>>>
>>> In this patch I chose to apply substitute-command-keys just once at the
>>> beginning of the function `widget-choose', rather than several times
>>> within the function, but I restricted its application to item tags, so
>>> other uses of the ITEMS argument should not be affected (and my brief
>>> testing hasn't found any problem with the patch).
>>
>> By moving the call to substitute-command-keys to the beginning, extended
>> menus simplified with widget--simplify-menu don't benefit anymore from
>> it. Perhaps that won't ever show up as a problem, but I think we should
>> guard against that.
>>
>> To do that, maybe widget--simplify-menu can call substitute-command-keys
>> when it builds the simplified menu.
>
> Thanks for the feedback. You're right, that patch is too superficial;
> it also fails to do substitution in popup extended menus like the one
> produced by clicking the "State" button, with the result that in the
> item "Revert This Session's Customization" the apostrophe is not
> displayed in the "curve" style. So I revised the patch, attached below,
> to iterate over the elements of each item in ITEMS, and it now appears
> to handle substitution with the "State" button display correctly, both
> as popup menu and as text menu buffer. The latter is the result of
> applying widget--simplify-menu, if I debugged correctly, so I think this
> answers your concerns (though the text menu buffer already shows the
> substitution independently of my patch, due to commit bd3b426ebb). Or
> have I misunderstood your concerns about widget--simplify-menu? If so,
> can you give an example where the new patch fails?
Just pinging in case this fell under the radar. If there's no response,
what's the next step forward?
Steve Berman
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.