bug#64046: 30.0.50; Quoting in customize choice tags

[Stephen Berman]

On Thu, 15 Jun 2023 13:39:34 +0200 Stephen Berman <stephen.berman@gmx.net> 
wrote:

> On Wed, 14 Jun 2023 17:05:32 -0300 Mauro Aranda <maurooaranda@gmail.com> 
> wrote:
>
>> Stephen Berman <stephen.berman@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