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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64046 in the body.
You can then email your comments to 64046 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Tue, 13 Jun 2023 14:04:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 13 Jun 2023 14:04:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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).
The patch also takes the opportunity to replace two unnecessary uses of
`let*' in `widget-choose', in one case by `let' and in the other by
foregoing let-bound variables altogether and just using the values in
place, since they occur only once each in the lines immediately
following the eliminated `let*'.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.6) of 2023-06-13 built on strobelfssd
Repository revision: ba349aa32e98a53146794197c316f4765598ddbd
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Linux From Scratch r11.3-100-systemd
Configured using:
'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM XWIDGETS GTK3 ZLIB
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Tue, 13 Jun 2023 15:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Tue, 13 Jun 2023 16:02:57 +0200
>
> 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).
>
> The patch also takes the opportunity to replace two unnecessary uses of
> `let*' in `widget-choose', in one case by `let' and in the other by
> foregoing let-bound variables altogether and just using the values in
> place, since they occur only once each in the lines immediately
> following the eliminated `let*'.
Thanks. I'm not familiar very well with widgets code, so I added
Mauro and Stefan to the discussion, in the hope that they will have
useful comments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 14 Jun 2023 19:52:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks. I'm not familiar very well with widgets code, so I added
> Mauro and Stefan to the discussion, in the hope that they will have
> useful comments.
Thanks for CCing me Eli. I'll take a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 14 Jun 2023 20:06:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 64046 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 15 Jun 2023 11:40:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 64046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
Steve Berman
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 22 Jun 2023 20:09:02 GMT)
Full text and
rfc822 format available.
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 22 Jun 2023 23:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
>> 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
It did, thanks for the ping.
Since there's no problem with widget--simplify-menu, the patch looks
good to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 23 Jun 2023 22:20:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>>> 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
>
> It did, thanks for the ping.
>
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 24 Jun 2023 06:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 64046 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>
> Date: Sat, 24 Jun 2023 00:18:48 +0200
>
> On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
> > Stephen Berman <stephen.berman <at> gmx.net> writes:
> >
> >>> 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
> >
> > It did, thanks for the ping.
> >
> > 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.
Pleased install on master. The problem is very minor and we have
lived with it for many years, so it can wait a bit more.
Thanks.
Reply sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
You have taken responsibility.
(Sat, 24 Jun 2023 08:51:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
bug acknowledged by developer.
(Sat, 24 Jun 2023 08:51:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 64046-done <at> debbugs.gnu.org (full text, mbox):
On Sat, 24 Jun 2023 09:37:34 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 64046 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier
>> <monnier <at> iro.umontreal.ca>
>> Date: Sat, 24 Jun 2023 00:18:48 +0200
>>
>> On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>>
>> > Stephen Berman <stephen.berman <at> gmx.net> writes:
>> >
>> >>> 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
>> >
>> > It did, thanks for the ping.
>> >
>> > 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.
>
> Pleased install on master. The problem is very minor and we have
> lived with it for many years, so it can wait a bit more.
Done with commit 6d55d93379f, closing the bug. Thanks.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 15 Jul 2023 13:21:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Thu, 22 Jun 2023 19:59:26 -0300 Mauro Aranda
<maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>>> 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
>>
>> It did, thanks for the ping.
>>
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 20 Jul 2023 15:49:02 GMT)
Full text and
rfc822 format available.
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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 20 Jul 2023 19:12:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda
<maurooaranda <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 20 Jul 2023 19:55:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 20 Jul 2023 16:11:33 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda <maurooaranda <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 18 Aug 2023 11:24:07 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Ola x Nilsson <ola.x.nilsson <at> axis.com>
to
control <at> debbugs.gnu.org.
(Mon, 21 Aug 2023 12:03:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Mon, 21 Aug 2023 12:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 20 2023, Stephen Berman wrote:
> On Thu, 20 Jul 2023 16:11:33 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda <maurooaranda <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Mon, 21 Aug 2023 14:52:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Ola x Nilsson <ola.x.nilsson <at> axis.com> writes:
> On Thu, Jul 20 2023, Stephen Berman wrote:
>
>> On Thu, 20 Jul 2023 16:11:33 -0300 Mauro Aranda
>> <maurooaranda <at> gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Sat, 15 Jul 2023 10:20:17 -0300 Mauro Aranda
<maurooaranda <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 12:52:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 64046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 21 Aug 2023 11:51:36 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Ola x Nilsson <ola.x.nilsson <at> axis.com> writes:
[...]
>> 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.
Thanks for reporting this regression. The following patch, which tests
for proper-list-p instead of consp, fixes the above case and still
applies substitute-command-keys correctly in the other cases brought up
in this bug:
[Message part 2 (text/x-patch, inline)]
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index a70598bb6c9..6b4446a0be8 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -285,7 +285,7 @@ widget-choose
;; Apply quote substitution to customize choice menu item text,
;; whether it occurs in a widget buffer or in a popup menu.
(let ((items (mapc (lambda (x)
- (when (consp x)
+ (when (proper-list-p x)
(dotimes (i (1- (length x)))
(when (stringp (nth i x))
(setcar (nthcdr i x)
[Message part 3 (text/plain, inline)]
However, if the car and cdr of the simple items are strings containing
grave-style quoting, e.g. as in the following:
(widget-choose "Title" '(("Use `a'" . "Use `a'") ("Use `b'" . "Use `b'")))
and this quoting is supposed to appear on evaluation as curve-style,
then something like the following patch seems to be required:
[Message part 4 (text/x-patch, inline)]
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index a70598bb6c9..40d7b5b902c 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -285,12 +285,17 @@ widget-choose
;; Apply quote substitution to customize choice menu item text,
;; whether it occurs in a widget buffer or in a popup menu.
(let ((items (mapc (lambda (x)
- (when (consp x)
- (dotimes (i (1- (length x)))
- (when (stringp (nth i x))
- (setcar (nthcdr i x)
- (substitute-command-keys
- (car (nthcdr i x))))))))
+ (if (proper-list-p x)
+ (dotimes (i (1- (length x)))
+ (when (stringp (nth i x))
+ (setcar (nthcdr i x)
+ (substitute-command-keys
+ (car (nthcdr i x))))))
+ ;; ITEMS has simple item definitions.
+ (when (and (consp x) (stringp (car x))
+ (stringp (cdr x)))
+ (setcar x (substitute-command-keys (car x)))
+ (setcdr x (substitute-command-keys (cdr x))))))
items)))
(cond ((and (< (length items) widget-menu-max-size)
event (display-popup-menus-p))
[Message part 5 (text/plain, inline)]
I don't see any obvious problem with this, but I'm not sure.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 13:20:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 64046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 24 Aug 2023 14:51:39 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Mon, 21 Aug 2023 11:51:36 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
>
>> Ola x Nilsson <ola.x.nilsson <at> axis.com> writes:
> [...]
>>> 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.
>
> Thanks for reporting this regression. The following patch, which tests
> for proper-list-p instead of consp, fixes the above case and still
> applies substitute-command-keys correctly in the other cases brought up
> in this bug:
>
> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
> index a70598bb6c9..6b4446a0be8 100644
> --- a/lisp/wid-edit.el
> +++ b/lisp/wid-edit.el
> @@ -285,7 +285,7 @@ widget-choose
> ;; Apply quote substitution to customize choice menu item text,
> ;; whether it occurs in a widget buffer or in a popup menu.
> (let ((items (mapc (lambda (x)
> - (when (consp x)
> + (when (proper-list-p x)
> (dotimes (i (1- (length x)))
> (when (stringp (nth i x))
> (setcar (nthcdr i x)
>
>
> However, if the car and cdr of the simple items are strings containing
> grave-style quoting, e.g. as in the following:
>
> (widget-choose "Title" '(("Use `a'" . "Use `a'") ("Use `b'" . "Use `b'")))
>
> and this quoting is supposed to appear on evaluation as curve-style,
> then something like the following patch seems to be required:
>
> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
> index a70598bb6c9..40d7b5b902c 100644
> --- a/lisp/wid-edit.el
> +++ b/lisp/wid-edit.el
> @@ -285,12 +285,17 @@ widget-choose
> ;; Apply quote substitution to customize choice menu item text,
> ;; whether it occurs in a widget buffer or in a popup menu.
> (let ((items (mapc (lambda (x)
> - (when (consp x)
> - (dotimes (i (1- (length x)))
> - (when (stringp (nth i x))
> - (setcar (nthcdr i x)
> - (substitute-command-keys
> - (car (nthcdr i x))))))))
> + (if (proper-list-p x)
> + (dotimes (i (1- (length x)))
> + (when (stringp (nth i x))
> + (setcar (nthcdr i x)
> + (substitute-command-keys
> + (car (nthcdr i x))))))
> + ;; ITEMS has simple item definitions.
> + (when (and (consp x) (stringp (car x))
> + (stringp (cdr x)))
> + (setcar x (substitute-command-keys (car x)))
> + (setcdr x (substitute-command-keys (cdr x))))))
> items)))
> (cond ((and (< (length items) widget-menu-max-size)
> event (display-popup-menus-p))
>
>
> I don't see any obvious problem with this, but I'm not sure.
Right after sending, I found an obvious problem: only one of the car or
the cdr might be a string. The following patch accounts for this:
[Message part 2 (text/x-patch, inline)]
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index a70598bb6c9..891e98b6de5 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -285,12 +285,18 @@ widget-choose
;; Apply quote substitution to customize choice menu item text,
;; whether it occurs in a widget buffer or in a popup menu.
(let ((items (mapc (lambda (x)
- (when (consp x)
- (dotimes (i (1- (length x)))
- (when (stringp (nth i x))
- (setcar (nthcdr i x)
- (substitute-command-keys
- (car (nthcdr i x))))))))
+ (if (proper-list-p x)
+ (dotimes (i (1- (length x)))
+ (when (stringp (nth i x))
+ (setcar (nthcdr i x)
+ (substitute-command-keys
+ (car (nthcdr i x))))))
+ ;; ITEMS has simple item definitions.
+ (when (consp x)
+ (when (stringp (car x))
+ (setcar x (substitute-command-keys (car x))))
+ (when (stringp (cdr x))
+ (setcdr x (substitute-command-keys (cdr x)))))))
items)))
(cond ((and (< (length items) widget-menu-max-size)
event (display-popup-menus-p))
[Message part 3 (text/plain, inline)]
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 20:16:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> Right after sending, I found an obvious problem: only one of the car or
> the cdr might be a string. The following patch accounts for this:
>
> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
> index a70598bb6c9..891e98b6de5 100644
> --- a/lisp/wid-edit.el
> +++ b/lisp/wid-edit.el
> @@ -285,12 +285,18 @@ widget-choose
> ;; Apply quote substitution to customize choice menu item text,
> ;; whether it occurs in a widget buffer or in a popup menu.
> (let ((items (mapc (lambda (x)
> - (when (consp x)
> - (dotimes (i (1- (length x)))
> - (when (stringp (nth i x))
> - (setcar (nthcdr i x)
> - (substitute-command-keys
> - (car (nthcdr i x))))))))
> + (if (proper-list-p x)
> + (dotimes (i (1- (length x)))
> + (when (stringp (nth i x))
> + (setcar (nthcdr i x)
> + (substitute-command-keys
> + (car (nthcdr i x))))))
> + ;; ITEMS has simple item definitions.
> + (when (consp x)
> + (when (stringp (car x))
> + (setcar x (substitute-command-keys (car
x))))
> + (when (stringp (cdr x))
> + (setcdr x (substitute-command-keys (cdr
x)))))))
Thinking about it, why do we need to call substitute-command-keys on the
VALUE part (i.e., the cdr of the cons cell), in case of simple item
definitions?
I re-read the bug report, but I didn't find any reference to why that is
a need. Did I miss something?
(I'll be going on a trip for the weekend, so apologies if I can't
see your response soon enough)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 20:54:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> > diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
> > index a70598bb6c9..40d7b5b902c 100644
> > --- a/lisp/wid-edit.el
> > +++ b/lisp/wid-edit.el
> > @@ -285,12 +285,17 @@ widget-choose
> > ;; Apply quote substitution to customize choice menu item text,
> > ;; whether it occurs in a widget buffer or in a popup menu.
Could `substitute-quotes' replace `substitute-command-keys' here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 20:55:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> Right after sending, I found an obvious problem: only one of the car or
>> the cdr might be a string. The following patch accounts for this:
>>
>> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
>> index a70598bb6c9..891e98b6de5 100644
>> --- a/lisp/wid-edit.el
>> +++ b/lisp/wid-edit.el
>> @@ -285,12 +285,18 @@ widget-choose
>> ;; Apply quote substitution to customize choice menu item text,
>> ;; whether it occurs in a widget buffer or in a popup menu.
>> (let ((items (mapc (lambda (x)
>> - (when (consp x)
>> - (dotimes (i (1- (length x)))
>> - (when (stringp (nth i x))
>> - (setcar (nthcdr i x)
>> - (substitute-command-keys
>> - (car (nthcdr i x))))))))
>> + (if (proper-list-p x)
>> + (dotimes (i (1- (length x)))
>> + (when (stringp (nth i x))
>> + (setcar (nthcdr i x)
>> + (substitute-command-keys
>> + (car (nthcdr i x))))))
>> + ;; ITEMS has simple item definitions.
>> + (when (consp x)
>> + (when (stringp (car x))
>> + (setcar x (substitute-command-keys (car x))))
>> + (when (stringp (cdr x))
>> + (setcdr x (substitute-command-keys (cdr
> x)))))))
>
> Thinking about it, why do we need to call substitute-command-keys on the
> VALUE part (i.e., the cdr of the cons cell), in case of simple item
> definitions?
>
> I re-read the bug report, but I didn't find any reference to why that is
> a need. Did I miss something?
Well, the VALUE is displayed on entering a choice. That is, when I do
M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'" . "Use `2'")))
I see curve-quoting in the widget-choose buffer:
Available choices:
0 = Use ‘a’
1 = Use ‘b’
C-g = Quit
and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
substitute-command-keys on the cdr in widget-choose, then typing `0' at
the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
don't know which one is the intended result.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 21:11:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 24 Aug 2023 22:53:02 +0200 Stefan Kangas <stefankangas <at> gmail.com> wrote:
>> > diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
>> > index a70598bb6c9..40d7b5b902c 100644
>> > --- a/lisp/wid-edit.el
>> > +++ b/lisp/wid-edit.el
>> > @@ -285,12 +285,17 @@ widget-choose
>> > ;; Apply quote substitution to customize choice menu item text,
>> > ;; whether it occurs in a widget buffer or in a popup menu.
>
> Could `substitute-quotes' replace `substitute-command-keys' here?
That indeed gives the same results for the cases discussed in this bug.
I used substitute-command-keys because it was already being used in
widget-choose before I installed my first change, which expanded its use
there. I don't know if there are cases covered by
substitute-command-keys and not but substitute-quotes that are relevant
for widget-choose; are there?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 21:15:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> That indeed gives the same results for the cases discussed in this bug.
> I used substitute-command-keys because it was already being used in
> widget-choose before I installed my first change, which expanded its use
> there. I don't know if there are cases covered by
> substitute-command-keys and not but substitute-quotes that are relevant
> for widget-choose; are there?
s-q only handles ` and ', while s-c-k handles full docstring syntax.
Does that help answer the question?
If we're not sure, the simplification is probably not worth it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 21:42:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, 24 Aug 2023 23:14:06 +0200 Stefan Kangas <stefankangas <at> gmail.com> wrote:
>> That indeed gives the same results for the cases discussed in this bug.
>> I used substitute-command-keys because it was already being used in
>> widget-choose before I installed my first change, which expanded its use
>> there. I don't know if there are cases covered by
>> substitute-command-keys and not but substitute-quotes that are relevant
>> for widget-choose; are there?
>
> s-q only handles ` and ', while s-c-k handles full docstring syntax.
>
> Does that help answer the question?
I had already looked at the code so I saw the difference. But I don't
know if there are any uses of widget-choose that include more docstring
syntax than quoting, or if anyone might want to use widget-choose in
such a way (if it's possible, which I also don't know).
> If we're not sure, the simplification is probably not worth it.
We could just make the simplification and see if gives rise to
complaints. On the other hand, I suspect the overhead of s-c-k would
not be very noticeable, unless perhaps someone has a gigantic user
option with lots of quoting.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 24 Aug 2023 22:00:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda
<maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> Right after sending, I found an obvious problem: only one of the car or
>>> the cdr might be a string. The following patch accounts for this:
>>>
>>> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
>>> index a70598bb6c9..891e98b6de5 100644
>>> --- a/lisp/wid-edit.el
>>> +++ b/lisp/wid-edit.el
>>> @@ -285,12 +285,18 @@ widget-choose
>>> ;; Apply quote substitution to customize choice menu item text,
>>> ;; whether it occurs in a widget buffer or in a popup menu.
>>> (let ((items (mapc (lambda (x)
>>> - (when (consp x)
>>> - (dotimes (i (1- (length x)))
>>> - (when (stringp (nth i x))
>>> - (setcar (nthcdr i x)
>>> - (substitute-command-keys
>>> - (car (nthcdr i x))))))))
>>> + (if (proper-list-p x)
>>> + (dotimes (i (1- (length x)))
>>> + (when (stringp (nth i x))
>>> + (setcar (nthcdr i x)
>>> + (substitute-command-keys
>>> + (car (nthcdr i x))))))
>>> + ;; ITEMS has simple item definitions.
>>> + (when (consp x)
>>> + (when (stringp (car x))
>>> + (setcar x (substitute-command-keys
(car x))))
>>> + (when (stringp (cdr x))
>>> + (setcdr x (substitute-command-keys (cdr
>> x)))))))
>>
>> Thinking about it, why do we need to call substitute-command-keys on the
>> VALUE part (i.e., the cdr of the cons cell), in case of simple item
>> definitions?
>>
>> I re-read the bug report, but I didn't find any reference to why that is
>> a need. Did I miss something?
>
> Well, the VALUE is displayed on entering a choice. That is, when I do
>
> M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'" .
"Use `2'")))
>
> I see curve-quoting in the widget-choose buffer:
>
> Available choices:
>
> 0 = Use ‘a’
> 1 = Use ‘b’
>
> C-g = Quit
>
> and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
> displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
> substitute-command-keys on the cdr in widget-choose, then typing `0' at
> the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
> don't know which one is the intended result.
I see, thank you. Your last patch looks good to me, then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 25 Aug 2023 08:05:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Thu, Aug 24 2023, Mauro Aranda wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda
> <maurooaranda <at> gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> Right after sending, I found an obvious problem: only one of the car or
>>>> the cdr might be a string. The following patch accounts for this:
>>>>
>>>> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
>>>> index a70598bb6c9..891e98b6de5 100644
>>>> --- a/lisp/wid-edit.el
>>>> +++ b/lisp/wid-edit.el
>>>> @@ -285,12 +285,18 @@ widget-choose
>>>> ;; Apply quote substitution to customize choice menu item text,
>>>> ;; whether it occurs in a widget buffer or in a popup menu.
>>>> (let ((items (mapc (lambda (x)
>>>> - (when (consp x)
>>>> - (dotimes (i (1- (length x)))
>>>> - (when (stringp (nth i x))
>>>> - (setcar (nthcdr i x)
>>>> - (substitute-command-keys
>>>> - (car (nthcdr i x))))))))
>>>> + (if (proper-list-p x)
>>>> + (dotimes (i (1- (length x)))
>>>> + (when (stringp (nth i x))
>>>> + (setcar (nthcdr i x)
>>>> + (substitute-command-keys
>>>> + (car (nthcdr i x))))))
>>>> + ;; ITEMS has simple item definitions.
>>>> + (when (consp x)
>>>> + (when (stringp (car x))
>>>> + (setcar x (substitute-command-keys
> (car x))))
>>>> + (when (stringp (cdr x))
>>>> + (setcdr x (substitute-command-keys (cdr
>>> x)))))))
>>>
>>> Thinking about it, why do we need to call substitute-command-keys on the
>>> VALUE part (i.e., the cdr of the cons cell), in case of simple item
>>> definitions?
>>>
>>> I re-read the bug report, but I didn't find any reference to why that is
>>> a need. Did I miss something?
>>
>> Well, the VALUE is displayed on entering a choice. That is, when I do
>>
>> M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'"
> . "Use `2'")))
>>
>> I see curve-quoting in the widget-choose buffer:
>>
>> Available choices:
>>
>> 0 = Use ‘a’
>> 1 = Use ‘b’
>>
>> C-g = Quit
>>
>> and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
>> displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
>> substitute-command-keys on the cdr in widget-choose, then typing `0' at
>> the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
>> don't know which one is the intended result.
>
> I see, thank you. Your last patch looks good to me, then.
The cdr is the return value, I would expect widget-choose to not
modify that.
--
Ola x Nilsson
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 25 Aug 2023 21:51:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Fri, 25 Aug 2023 10:02:35 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com> wrote:
> On Thu, Aug 24 2023, Mauro Aranda wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda
>> <maurooaranda <at> gmail.com> wrote:
[...]
>>>> Thinking about it, why do we need to call substitute-command-keys on the
>>>> VALUE part (i.e., the cdr of the cons cell), in case of simple item
>>>> definitions?
>>>>
>>>> I re-read the bug report, but I didn't find any reference to why that is
>>>> a need. Did I miss something?
>>>
>>> Well, the VALUE is displayed on entering a choice. That is, when I do
>>>
>>> M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'"
>> . "Use `2'")))
>>>
>>> I see curve-quoting in the widget-choose buffer:
>>>
>>> Available choices:
>>>
>>> 0 = Use ‘a’
>>> 1 = Use ‘b’
>>>
>>> C-g = Quit
>>>
>>> and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
>>> displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
>>> substitute-command-keys on the cdr in widget-choose, then typing `0' at
>>> the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
>>> don't know which one is the intended result.
>>
>> I see, thank you. Your last patch looks good to me, then.
>
> The cdr is the return value, I would expect widget-choose to not
> modify that.
I think this is indeed the correct expectation and I should have
recognized it instead of looking only at appearances. But do you agree
that applying (at least) quote substitution to the car of the simple
item definition is appropriate here? If so, there is still the question
of whether to use substitute-command-keys or just substitute-quotes.
I'm inclined to stick with the former but would be fine with going with
the latter.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Mon, 28 Aug 2023 09:41:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Fri, Aug 25 2023, Stephen Berman wrote:
> On Fri, 25 Aug 2023 10:02:35 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com> wrote:
>
>> On Thu, Aug 24 2023, Mauro Aranda wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda
>>> <maurooaranda <at> gmail.com> wrote:
> [...]
>>>>> Thinking about it, why do we need to call substitute-command-keys on the
>>>>> VALUE part (i.e., the cdr of the cons cell), in case of simple item
>>>>> definitions?
>>>>>
>>>>> I re-read the bug report, but I didn't find any reference to why that is
>>>>> a need. Did I miss something?
>>>>
>>>> Well, the VALUE is displayed on entering a choice. That is, when I do
>>>>
>>>> M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'"
>>> . "Use `2'")))
>>>>
>>>> I see curve-quoting in the widget-choose buffer:
>>>>
>>>> Available choices:
>>>>
>>>> 0 = Use ‘a’
>>>> 1 = Use ‘b’
>>>>
>>>> C-g = Quit
>>>>
>>>> and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
>>>> displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
>>>> substitute-command-keys on the cdr in widget-choose, then typing `0' at
>>>> the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
>>>> don't know which one is the intended result.
>>>
>>> I see, thank you. Your last patch looks good to me, then.
>>
>> The cdr is the return value, I would expect widget-choose to not
>> modify that.
>
> I think this is indeed the correct expectation and I should have
> recognized it instead of looking only at appearances. But do you agree
> that applying (at least) quote substitution to the car of the simple
> item definition is appropriate here? If so, there is still the question
> of whether to use substitute-command-keys or just substitute-quotes.
> I'm inclined to stick with the former but would be fine with going with
> the latter.
I agree that quote substition should be done on the car of simple item
definitions. I have no opinion on susbstitute-command-keys vs
substitute-quotes. But I came to think about the TITLE argument,
shouldn't quote substition be performed on it as well?
/Ola
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Mon, 28 Aug 2023 13:51:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 64046 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com> wrote:
> On Fri, Aug 25 2023, Stephen Berman wrote:
>
>> On Fri, 25 Aug 2023 10:02:35 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com> wrote:
>>
>>> On Thu, Aug 24 2023, Mauro Aranda wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> On Thu, 24 Aug 2023 17:14:53 -0300 Mauro Aranda
>>>> <maurooaranda <at> gmail.com> wrote:
>> [...]
>>>>>> Thinking about it, why do we need to call substitute-command-keys on the
>>>>>> VALUE part (i.e., the cdr of the cons cell), in case of simple item
>>>>>> definitions?
>>>>>>
>>>>>> I re-read the bug report, but I didn't find any reference to why that is
>>>>>> a need. Did I miss something?
>>>>>
>>>>> Well, the VALUE is displayed on entering a choice. That is, when I do
>>>>>
>>>>> M-: (widget-choose "Title" '(("Use `a'" . "Use `1'") ("Use `b'"
>>>> . "Use `2'")))
>>>>>
>>>>> I see curve-quoting in the widget-choose buffer:
>>>>>
>>>>> Available choices:
>>>>>
>>>>> 0 = Use ‘a’
>>>>> 1 = Use ‘b’
>>>>>
>>>>> C-g = Quit
>>>>>
>>>>> and when I enter e.g. `0' at the "Title: " prompt in the minibuffer, it
>>>>> displays "Use ‘1’", i.e., with curve-quoting. But if I omit the call to
>>>>> substitute-command-keys on the cdr in widget-choose, then typing `0' at
>>>>> the "Title: " prompt displays "Use `1'", i.e. with grave-quoting. But I
>>>>> don't know which one is the intended result.
>>>>
>>>> I see, thank you. Your last patch looks good to me, then.
>>>
>>> The cdr is the return value, I would expect widget-choose to not
>>> modify that.
>>
>> I think this is indeed the correct expectation and I should have
>> recognized it instead of looking only at appearances. But do you agree
>> that applying (at least) quote substitution to the car of the simple
>> item definition is appropriate here? If so, there is still the question
>> of whether to use substitute-command-keys or just substitute-quotes.
>> I'm inclined to stick with the former but would be fine with going with
>> the latter.
>
> I agree that quote substition should be done on the car of simple item
> definitions. I have no opinion on susbstitute-command-keys vs
> substitute-quotes. But I came to think about the TITLE argument,
> shouldn't quote substition be performed on it as well?
I think you're right about that as well, since the title is simply a
display feature. AFAIK it wouldn't make a noticeable difference for
existing uses of widget-choose in the Customize UI (in the Value menu
the title is simply "Choice" and in the State menu it's "Operation on
<option name>"), but it might be relevant for third party uses or future
uses in Emacs, as well as for ad-hoc uses of simple item definitions.
So applying substition to all uses of TITLE seems appropriate. The
below patch does this, and also corrects my previous patch by excluding
substition from the cdr of simple item definitions.
Thanks for your feedback.
Steve Berman
[Message part 2 (text/x-patch, inline)]
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index a70598bb6c9..b712be1986b 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -282,16 +282,20 @@ widget-choose
If ITEMS has simple item definitions, then this function returns the VALUE of
the chosen element. If ITEMS is a keymap, then the return value is the symbol
in the key vector, as in the argument of `define-key'."
- ;; Apply quote substitution to customize choice menu item text,
+ ;; Apply quote substitution to choice menu title and item text,
;; whether it occurs in a widget buffer or in a popup menu.
(let ((items (mapc (lambda (x)
- (when (consp x)
- (dotimes (i (1- (length x)))
- (when (stringp (nth i x))
- (setcar (nthcdr i x)
- (substitute-command-keys
- (car (nthcdr i x))))))))
- items)))
+ (if (proper-list-p x)
+ (dotimes (i (1- (length x)))
+ (when (stringp (nth i x))
+ (setcar (nthcdr i x)
+ (substitute-command-keys
+ (car (nthcdr i x))))))
+ ;; ITEMS has simple item definitions.
+ (when (and (consp x) (stringp (car x)))
+ (setcar x (substitute-command-keys (car x))))))
+ items))
+ (title (substitute-command-keys title)))
(cond ((and (< (length items) widget-menu-max-size)
event (display-popup-menus-p))
;; Mouse click.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 30 Aug 2023 15:31:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson
<ola.x.nilsson <at> axis.com> wrote:
>
>> I agree that quote substition should be done on the car of simple item
>> definitions. I have no opinion on susbstitute-command-keys vs
>> substitute-quotes. But I came to think about the TITLE argument,
>> shouldn't quote substition be performed on it as well?
>
> I think you're right about that as well, since the title is simply a
> display feature. AFAIK it wouldn't make a noticeable difference for
> existing uses of widget-choose in the Customize UI (in the Value menu
> the title is simply "Choice" and in the State menu it's "Operation on
> <option name>"), but it might be relevant for third party uses or future
> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
> So applying substition to all uses of TITLE seems appropriate. The
> below patch does this, and also corrects my previous patch by excluding
> substition from the cdr of simple item definitions.
What would be a real-life scenario where we need to use
substitute-command-keys on TITLE? I can't think of any.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 30 Aug 2023 16:31:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Wed, 30 Aug 2023 12:29:47 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com>
> wrote:
>>
>>> I agree that quote substition should be done on the car of simple item
>>> definitions. I have no opinion on susbstitute-command-keys vs
>>> substitute-quotes. But I came to think about the TITLE argument,
>>> shouldn't quote substition be performed on it as well?
>>
>> I think you're right about that as well, since the title is simply a
>> display feature. AFAIK it wouldn't make a noticeable difference for
>> existing uses of widget-choose in the Customize UI (in the Value menu
>> the title is simply "Choice" and in the State menu it's "Operation on
>> <option name>"), but it might be relevant for third party uses or future
>> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
>> So applying substition to all uses of TITLE seems appropriate. The
>> below patch does this, and also corrects my previous patch by excluding
>> substition from the cdr of simple item definitions.
>
> What would be a real-life scenario where we need to use
> substitute-command-keys on TITLE? I can't think of any.
I can't think of a really convincing example where it's needed, but just
as a possibility for stylistic variation, e.g. for simple item
definitions one could have a more explicit prompt like this:
(widget-choose "Type `0' or `1'" '(("Use `a'" . "Use `1'") ("Use `b'" . "Use `2'")))
which would appear as "Type ‘0’ or ‘1’" with curve-style quotes. For
the Customize UI, although the title is currently hard-coded as
"Choice", one could define a widget with a title like "User's choice",
which would appear as "User’s choice" with the curve-style quote.
Unless some undesirable consequence of applying substitute-command-keys
to TITLE is found, I don't see any harm in allowing such uses.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 30 Aug 2023 22:34:03 GMT)
Full text and
rfc822 format available.
Message #104 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Wed, 30 Aug 2023 12:29:47 -0300 Mauro Aranda
<maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson
<ola.x.nilsson <at> axis.com>
>> wrote:
>>>
>>>> I agree that quote substition should be done on the car of simple item
>>>> definitions. I have no opinion on susbstitute-command-keys vs
>>>> substitute-quotes. But I came to think about the TITLE argument,
>>>> shouldn't quote substition be performed on it as well?
>>>
>>> I think you're right about that as well, since the title is simply a
>>> display feature. AFAIK it wouldn't make a noticeable difference for
>>> existing uses of widget-choose in the Customize UI (in the Value menu
>>> the title is simply "Choice" and in the State menu it's "Operation on
>>> <option name>"), but it might be relevant for third party uses or
future
>>> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
>>> So applying substition to all uses of TITLE seems appropriate. The
>>> below patch does this, and also corrects my previous patch by excluding
>>> substition from the cdr of simple item definitions.
>>
>> What would be a real-life scenario where we need to use
>> substitute-command-keys on TITLE? I can't think of any.
>
> I can't think of a really convincing example where it's needed, but just
> as a possibility for stylistic variation, e.g. for simple item
> definitions one could have a more explicit prompt like this:
>
> (widget-choose "Type `0' or `1'" '(("Use `a'" . "Use `1'") ("Use `b'"
> . "Use `2'")))
>
> which would appear as "Type ‘0’ or ‘1’" with curve-style quotes. For
> the Customize UI, although the title is currently hard-coded as
> "Choice", one could define a widget with a title like "User's choice",
> which would appear as "User’s choice" with the curve-style quote.
> Unless some undesirable consequence of applying substitute-command-keys
> to TITLE is found, I don't see any harm in allowing such uses.
I vote for don't adding code until it's really needed, and since there
isn't a real feature request for that, I'd leave it out. Looks like we
disagree on this, and it's not really my call, so let's leave it for a
maintainer to decide whether to add that line of code or not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 30 Aug 2023 22:53:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Wed, 30 Aug 2023 19:33:21 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Wed, 30 Aug 2023 12:29:47 -0300 Mauro Aranda <maurooaranda <at> gmail.com>
> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson <ola.x.nilsson <at> axis.com>
>>> wrote:
>>>>
>>>>> I agree that quote substition should be done on the car of simple item
>>>>> definitions. I have no opinion on susbstitute-command-keys vs
>>>>> substitute-quotes. But I came to think about the TITLE argument,
>>>>> shouldn't quote substition be performed on it as well?
>>>>
>>>> I think you're right about that as well, since the title is simply a
>>>> display feature. AFAIK it wouldn't make a noticeable difference for
>>>> existing uses of widget-choose in the Customize UI (in the Value menu
>>>> the title is simply "Choice" and in the State menu it's "Operation on
>>>> <option name>"), but it might be relevant for third party uses or future
>>>> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
>>>> So applying substition to all uses of TITLE seems appropriate. The
>>>> below patch does this, and also corrects my previous patch by excluding
>>>> substition from the cdr of simple item definitions.
>>>
>>> What would be a real-life scenario where we need to use
>>> substitute-command-keys on TITLE? I can't think of any.
>>
>> I can't think of a really convincing example where it's needed, but just
>> as a possibility for stylistic variation, e.g. for simple item
>> definitions one could have a more explicit prompt like this:
>>
>> (widget-choose "Type `0' or `1'" '(("Use `a'" . "Use `1'") ("Use `b'"
>> . "Use `2'")))
>>
>> which would appear as "Type ‘0’ or ‘1’" with curve-style quotes. For
>> the Customize UI, although the title is currently hard-coded as
>> "Choice", one could define a widget with a title like "User's choice",
>> which would appear as "User’s choice" with the curve-style quote.
>> Unless some undesirable consequence of applying substitute-command-keys
>> to TITLE is found, I don't see any harm in allowing such uses.
>
> I vote for don't adding code until it's really needed, and since there
> isn't a real feature request for that, I'd leave it out.
Well, I took Ola Nilsson's post which drew attention to the possibility
of applying quote substition to TITLE (quoted above), as an implicit
feature request, and found it plausible. But...
> Looks like we
> disagree on this, and it's not really my call, so let's leave it for a
> maintainer to decide whether to add that line of code or not.
... I don't have any problem leaving TITLE alone for now. And I do
agree with you that an Emacs maintainer should make the decision (also
about whether to retain substitute-command-keys or instead use
substitute-quotes).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Wed, 30 Aug 2023 22:59:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Wed, 30 Aug 2023 19:33:21 -0300 Mauro Aranda
<maurooaranda <at> gmail.com> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Wed, 30 Aug 2023 12:29:47 -0300 Mauro Aranda
<maurooaranda <at> gmail.com>
>> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson
<ola.x.nilsson <at> axis.com>
>>>> wrote:
>>>>>
>>>>>> I agree that quote substition should be done on the car of
simple item
>>>>>> definitions. I have no opinion on susbstitute-command-keys vs
>>>>>> substitute-quotes. But I came to think about the TITLE argument,
>>>>>> shouldn't quote substition be performed on it as well?
>>>>>
>>>>> I think you're right about that as well, since the title is simply a
>>>>> display feature. AFAIK it wouldn't make a noticeable difference for
>>>>> existing uses of widget-choose in the Customize UI (in the Value menu
>>>>> the title is simply "Choice" and in the State menu it's "Operation on
>>>>> <option name>"), but it might be relevant for third party uses or
future
>>>>> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
>>>>> So applying substition to all uses of TITLE seems appropriate. The
>>>>> below patch does this, and also corrects my previous patch by
excluding
>>>>> substition from the cdr of simple item definitions.
>>>>
>>>> What would be a real-life scenario where we need to use
>>>> substitute-command-keys on TITLE? I can't think of any.
>>>
>>> I can't think of a really convincing example where it's needed, but
just
>>> as a possibility for stylistic variation, e.g. for simple item
>>> definitions one could have a more explicit prompt like this:
>>>
>>> (widget-choose "Type `0' or `1'" '(("Use `a'" . "Use `1'") ("Use `b'"
>>> . "Use `2'")))
>>>
>>> which would appear as "Type ‘0’ or ‘1’" with curve-style quotes. For
>>> the Customize UI, although the title is currently hard-coded as
>>> "Choice", one could define a widget with a title like "User's choice",
>>> which would appear as "User’s choice" with the curve-style quote.
>>> Unless some undesirable consequence of applying substitute-command-keys
>>> to TITLE is found, I don't see any harm in allowing such uses.
>>
>> I vote for don't adding code until it's really needed, and since there
>> isn't a real feature request for that, I'd leave it out.
>
> Well, I took Ola Nilsson's post which drew attention to the possibility
> of applying quote substition to TITLE (quoted above), as an implicit
> feature request, and found it plausible. But...
>
>> Looks like we
>> disagree on this, and it's not really my call, so let's leave it for a
>> maintainer to decide whether to add that line of code or not.
>
> ... I don't have any problem leaving TITLE alone for now. And I do
> agree with you that an Emacs maintainer should make the decision (also
> about whether to retain substitute-command-keys or instead use
> substitute-quotes).
Let's wait then. And thank you for taking the time to write the code
for it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 05:43:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> Cc: Ola x Nilsson <ola.x.nilsson <at> axis.com>, 64046 <at> debbugs.gnu.org
> Date: Wed, 30 Aug 2023 19:58:26 -0300
> From: Mauro Aranda <maurooaranda <at> gmail.com>
>
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
> > On Wed, 30 Aug 2023 19:33:21 -0300 Mauro Aranda
> <maurooaranda <at> gmail.com> wrote:
> >
> >> Stephen Berman <stephen.berman <at> gmx.net> writes:
> >>
> >>> On Wed, 30 Aug 2023 12:29:47 -0300 Mauro Aranda
> <maurooaranda <at> gmail.com>
> >> wrote:
> >>>
> >>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
> >>>>
> >>>>> On Mon, 28 Aug 2023 11:33:09 +0200 Ola x Nilsson
> <ola.x.nilsson <at> axis.com>
> >>>> wrote:
> >>>>>
> >>>>>> I agree that quote substition should be done on the car of
> simple item
> >>>>>> definitions. I have no opinion on susbstitute-command-keys vs
> >>>>>> substitute-quotes. But I came to think about the TITLE argument,
> >>>>>> shouldn't quote substition be performed on it as well?
> >>>>>
> >>>>> I think you're right about that as well, since the title is simply a
> >>>>> display feature. AFAIK it wouldn't make a noticeable difference for
> >>>>> existing uses of widget-choose in the Customize UI (in the Value menu
> >>>>> the title is simply "Choice" and in the State menu it's "Operation on
> >>>>> <option name>"), but it might be relevant for third party uses or
> future
> >>>>> uses in Emacs, as well as for ad-hoc uses of simple item definitions.
> >>>>> So applying substition to all uses of TITLE seems appropriate. The
> >>>>> below patch does this, and also corrects my previous patch by
> excluding
> >>>>> substition from the cdr of simple item definitions.
> >>>>
> >>>> What would be a real-life scenario where we need to use
> >>>> substitute-command-keys on TITLE? I can't think of any.
> >>>
> >>> I can't think of a really convincing example where it's needed, but
> just
> >>> as a possibility for stylistic variation, e.g. for simple item
> >>> definitions one could have a more explicit prompt like this:
> >>>
> >>> (widget-choose "Type `0' or `1'" '(("Use `a'" . "Use `1'") ("Use `b'"
> >>> . "Use `2'")))
> >>>
> >>> which would appear as "Type ‘0’ or ‘1’" with curve-style quotes. For
> >>> the Customize UI, although the title is currently hard-coded as
> >>> "Choice", one could define a widget with a title like "User's choice",
> >>> which would appear as "User’s choice" with the curve-style quote.
> >>> Unless some undesirable consequence of applying substitute-command-keys
> >>> to TITLE is found, I don't see any harm in allowing such uses.
> >>
> >> I vote for don't adding code until it's really needed, and since there
> >> isn't a real feature request for that, I'd leave it out.
> >
> > Well, I took Ola Nilsson's post which drew attention to the possibility
> > of applying quote substition to TITLE (quoted above), as an implicit
> > feature request, and found it plausible. But...
> >
> >> Looks like we
> >> disagree on this, and it's not really my call, so let's leave it for a
> >> maintainer to decide whether to add that line of code or not.
> >
> > ... I don't have any problem leaving TITLE alone for now. And I do
> > agree with you that an Emacs maintainer should make the decision (also
> > about whether to retain substitute-command-keys or instead use
> > substitute-quotes).
>
> Let's wait then. And thank you for taking the time to write the code
> for it.
Stefan, any comments on this issue?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 06:44:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> Stefan, any comments on this issue?
Having re-read the discussion, I'd suggest:
1. Use `substitute-quotes' for the TITLE argument. We're using that
for display purposes here, so why not make it look a bit nicer and
more consistent.
2. Leave the pre-existing `substitute-command-keys' as-is to avoid
introducing any regressions. We can change it later if we find any
issues with it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 15:45:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> 1. Use `substitute-quotes' for the TITLE argument. We're using that
> for display purposes here, so why not make it look a bit nicer and
> more consistent.
Because it's _not_ nicer. Just leave it alone,
please.
You don't, and you can't, know ahead of time
"for display purposes" what "a bit nicer" means
or should mean. Such one-size-for-all treatment
just gets in the way. This is Emacs, and Lisp.
Anyone can massage a TITLE string ahead of time,
if they need to. Please make no assumptions
about the meaning of quotes - or any other chars
- in a title, including how they should appear.
Just leave all chars as they are.
Again, anyone can change the TITLE string if
needed, before submitting it. Users know what
they want/need better than design-time molders.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 20:53:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> > 1. Use `substitute-quotes' for the TITLE argument. We're using that
> > for display purposes here, so why not make it look a bit nicer and
> > more consistent.
>
> Because it's _not_ nicer. Just leave it alone,
> please.
Do you have an example of where it's not? I can't think of one, so
you'll have to help me here.
> Anyone can massage a TITLE string ahead of time,
> if they need to.
But the idea here is exactly the opposite: that they shouldn't have
to. So I don't think I understand your point.
BTW, if you don't like curved quotes you can always:
(setq text-quoting-style 'grave)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 22:12:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> > > 1. Use `substitute-quotes' for the TITLE argument. We're using that
> > > for display purposes here, so why not make it look a bit nicer and
> > > more consistent.
> >
> > Because it's _not_ nicer. Just leave it alone,
> > please.
>
> Do you have an example of where it's not? I can't think of one, so
> you'll have to help me here.
Don't need one. The TITLE can be _any_ text.
Who knows how ` and ' might be used? You don't,
any more than I do. Or if you do, please let us
know your assumptions about this: what gives you
the idea that they should always be translated
to curly quotes?
I think you don't know, as I don't know, what
someone might put in TITLE. I think that we
should leave it up to users to control what goes
there. Users can easily translate or replace
any ` and ' chars with curly quotes, if desired.
Why _impose_ such translation or make users
apply escape sequences to prevent it?
> > Anyone can massage a TITLE string ahead of time,
> > if they need to.
>
> But the idea here is exactly the opposite:
Exactly: the idea is to change the text users
give you into something else, automatically
and always. IMO, that's an unhelpful idea.
> that they shouldn't have to. So I don't
> think I understand your point.
See above. They shouldn't have to escape the
chars to _prevent_ your blanket, automatic
massaging.
Why not just take users' text as it is - take
their word for it - instead of second-guessing
them? Don't you think they can decide what's
best for themselves? Don't you think that if
they really want a curly quote they can use one?
> BTW, if you don't like curved quotes you can always:
> (setq text-quoting-style 'grave)
It's not about what I like. And it's not
about giving users only a blanket override.
It's about simply letting users provide the
TITLE text they want - just leave it alone.
If someone wants a curly quote they can get
it directly, on their own. But if they want
an apostrophe or backquote ... they have to
jump through an escape hoop? How is that
user-friendly? It's _their_ code.
"why not make it look a bit nicer" means you
think you know better than users what looks
nicer. And even if you're right in some case,
who says that this or that user wants their
TITLE to "look nicer"?
In effect, except through the compensation of
escaping, it's as if you've removed the chars
` and ' from the set of usable chars. Why do
that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Thu, 31 Aug 2023 23:01:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> > Do you have an example of where it's not? I can't think of one, so
> > you'll have to help me here.
>
> Don't need one. The TITLE can be _any_ text.
> Who knows how ` and ' might be used? You don't,
> any more than I do. Or if you do, please let us
> know your assumptions about this: what gives you
> the idea that they should always be translated
> to curly quotes?
I was convinced by Stephen Berman's arguments upthread. He spoke
about the specifics of this function, how it might typically be used,
and used examples to show why using curly quotes is a good idea here.
The reality is that we have decided to use curly quotes in Emacs, in
places where it is typographically correct. That decision was made
before I was very active in the project, BTW. So either we reverse
that decision, or we try to be consistent about it. My position is
that the latter is preferable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 01:10:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> > > Do you have an example of where it's not? I can't think of one, so
> > > you'll have to help me here.
> >
> > Don't need one. The TITLE can be _any_ text.
> > Who knows how ` and ' might be used? You don't,
> > any more than I do. Or if you do, please let us
> > know your assumptions about this: what gives you
> > the idea that they should always be translated
> > to curly quotes?
>
> I was convinced by Stephen Berman's arguments upthread. He spoke
> about the specifics of this function, how it might typically be used,
> and used examples to show why using curly quotes is a good idea here.
>
> The reality is that we have decided to use curly quotes in Emacs, in
> places where it is typographically correct. That decision was made
> before I was very active in the project, BTW. So either we reverse
> that decision, or we try to be consistent about it. My position is
> that the latter is preferable.
How does (a) a decision (however debatable its
merits) to convert ` and ' that surround key
descriptions, function names, variable names,
etc. in doc/help to curly quotes apply to, or
even relate to, (b) deciding to convert ` and '
to curly quotes in TITLE for the currently
considered context?
Has anyone spoken to that? Has anyone given
any reason, let alone good reasons, for doing
that? I haven't seen any reasons presented,
and I've asked you about it several times now.
Can you cite some reasons?
All I've seen are vague pronouncements that
doing that would produce TITLEs that are "a
bit nicer". An opinion as worthy as another
perhaps, but "I like it" is hardly a reason
why changing user TITLEs is preferable to
just leaving them well enough alone.
You can say "I like curly quotes", and I can
say "I like straight quotes". Opinions.
Goûts et couleurs.
But to me the real issue is leaving TITLEs
up to users. Users are perfectly capable of
deciding what _they_ prefer for their TITLEs.
Why don't you leave it alone, to start with,
and see whether there's a resulting torrent
of user requests to impose curliness on `...'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 06:18:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 1 Sep 2023 00:59:58 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, "stephen.berman <at> gmx.net" <stephen.berman <at> gmx.net>,
> "ola.x.nilsson <at> axis.com" <ola.x.nilsson <at> axis.com>, "64046 <at> debbugs.gnu.org" <64046 <at> debbugs.gnu.org>,
> Mauro Aranda <maurooaranda <at> gmail.com>
>
> Drew Adams <drew.adams <at> oracle.com> writes:
>
> > > Do you have an example of where it's not? I can't think of one, so
> > > you'll have to help me here.
> >
> > Don't need one. The TITLE can be _any_ text.
> > Who knows how ` and ' might be used? You don't,
> > any more than I do. Or if you do, please let us
> > know your assumptions about this: what gives you
> > the idea that they should always be translated
> > to curly quotes?
>
> I was convinced by Stephen Berman's arguments upthread. He spoke
> about the specifics of this function, how it might typically be used,
> and used examples to show why using curly quotes is a good idea here.
>
> The reality is that we have decided to use curly quotes in Emacs, in
> places where it is typographically correct. That decision was made
> before I was very active in the project, BTW. So either we reverse
> that decision, or we try to be consistent about it. My position is
> that the latter is preferable.
No, we will not reverse that decision. Conversion of quotes is
dynamic, it's sensitive to the display capabilities of the underlying
terminal, and includes enough knobs for people who don't want that to
disable it. I wish that Drew had finally accepted this as a fait
accompli and stopped raising the same arguments on every opportunity.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 06:36:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: Eli Zaretskii <eliz <at> gnu.org>,
> "stephen.berman <at> gmx.net"
> <stephen.berman <at> gmx.net>,
> "ola.x.nilsson <at> axis.com" <ola.x.nilsson <at> axis.com>,
> "64046 <at> debbugs.gnu.org" <64046 <at> debbugs.gnu.org>,
> Mauro Aranda
> <maurooaranda <at> gmail.com>
> Date: Fri, 1 Sep 2023 01:08:55 +0000
>
> > The reality is that we have decided to use curly quotes in Emacs, in
> > places where it is typographically correct. That decision was made
> > before I was very active in the project, BTW. So either we reverse
> > that decision, or we try to be consistent about it. My position is
> > that the latter is preferable.
>
> How does (a) a decision (however debatable its
> merits) to convert ` and ' that surround key
> descriptions, function names, variable names,
> etc. in doc/help to curly quotes apply to, or
> even relate to, (b) deciding to convert ` and '
> to curly quotes in TITLE for the currently
> considered context?
These conversions are broader in scope than you assume: they affect
_any_ quoting, not just quoting of symbols.
> Has anyone spoken to that? Has anyone given
> any reason, let alone good reasons, for doing
> that? I haven't seen any reasons presented,
> and I've asked you about it several times now.
The reasons were given many times. You just disagree with them, so
you post counter-arguments, and then behave like the reasons don't
exist because you posted counter-arguments.
> Can you cite some reasons?
What for? We had these discussions many times, with the same
arguments and the same outcomes. We should stop reiterating them and
wasting everyone's time and energy, let alone bandwidth.
> All I've seen are vague pronouncements that
> doing that would produce TITLEs that are "a
> bit nicer". An opinion as worthy as another
> perhaps, but "I like it" is hardly a reason
> why changing user TITLEs is preferable to
> just leaving them well enough alone.
You have an option to disable that if you don't like it.
> You can say "I like curly quotes", and I can
> say "I like straight quotes". Opinions.
The way Emacs deals with different opinions is to have user options.
We have one here, so please customize your sessions to your liking,
and let's stop these futile disputes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 16:19:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> > > The reality is that we have decided to use curly quotes in Emacs, in
> > > places where it is typographically correct. That decision was made
> > > before I was very active in the project, BTW. So either we reverse
> > > that decision, or we try to be consistent about it. My position is
> > > that the latter is preferable.
> >
> > How does (a) a decision (however debatable its
> > merits) to convert ` and ' that surround key
> > descriptions, function names, variable names,
> > etc. in doc/help to curly quotes apply to, or
> > even relate to, (b) deciding to convert ` and '
> > to curly quotes in TITLE for the currently
> > considered context?
>
> These conversions are broader in scope than you assume:
> they affect _any_ quoting, not just quoting of symbols.
I didn't refer to symbols. I mentioned the
things for which quoting with `...' gets
converted to quoting with curly quotes in
doc and help contexts (including msgs).
I gave examples of such text, which isn't
just symbol names.
"These conversations"? This bug thread is
specific to "Quoting in customize choice
tags". And my little part of it is much
more specific than that.
I've spoken only about TITLE, which AFAIK
can contain ANY text - text in which `...'
has no necessary meaning or correspondence
to the contexts (Info, Help) where curly
conversion was adopted - for sexps, file
names, etc.
I didn't say a thing about other places
referred to in this thread where `...'
would be converted to curly quotes - let
alone other places outside this thread.
Am I mistaken that TITLE can be anything
at all, and doesn't correspond to the
kinds of context where we've (you've)
adopted curly conversion of `...'?
If so, please let me know how - what's
the expectation for the text in TITLE?
> > Has anyone spoken to that? Has anyone given
> > any reason, let alone good reasons, for doing
> > that? I haven't seen any reasons presented,
> > and I've asked you about it several times now.
>
> The reasons were given many times. You just disagree with them, so
> you post counter-arguments, and then behave like the reasons don't
> exist because you posted counter-arguments.
You have a habit of saying that, instead of
pointing to any reasons.
I haven't seen any. No one has cited any.
Just saying, as you often do, that many
reasons have been given doesn't make it so,
as experience has shown.
And please contain your "reasons given many
times" to the content of this thread. It's
not about whatever reasons might have been
given years ago in some discussion about
the use of `...' in doc and help.
I do not "behave like the reasons don't
exist". I've asked to be pointed to them
- even one. And your repeated refrain of
there-are-lots-but-Drew-pretends-otherwise
rings hollow. You're the one harping on
the general (and settled) question of
treatment of `...', not I. It's you who
enjoys bringing that up.
And you have a bad habit of jumping into
ad hominem argument. Please stop that.
It's not because it's Drew who raises a
question that it should be dismissed.
Why change `...' in TITLE to curly quotes?
> > Can you cite some reasons?
>
> What for? We had these discussions many times, with the same
> arguments and the same outcomes. We should stop reiterating them and
> wasting everyone's time and energy, let alone bandwidth.
The only question I spoke to in this
thread was about TITLE. This isn't about
some general discussion about converting
`...' to curly quotes.
It's you, not I, who have tried to replace
a specific question about TITLE with a
discussion about converting `...' to curly
quotes in general. It's you who's trying
to initiate here-we-go-again, by painting
this as being about a more general topic.
I specifically did not say a word about
conversion of `...' to curly quotes in the
rest of this thread (where it was brought
up many times). Search the thread for
"substitu", if you don't believe me. Such
conversion is now being done in several
places for this thread. No problem.
TITLE seems different, to me. I _asked_
whether I'm wrong about that - whether
it's _not_ the case that TITLE is wide
open as to what it might contain, and
whether/why a ` or a ' char, or even a
`...' context, in TITLE should be handled
the way we handle sexps, file names, etc.
in Info and Help.
I'm no expert on TITLE or quoting in
customize choice tags. So I raised the
_question_ (actually, it was raised
before me). I don't see why TITLE should
have its text converted.
No response to that question. I'd really
like to know why TITLE should be treated
the same as text that talks about sexps
etc., i.e., the same as Info and Help.
> > All I've seen are vague pronouncements that
> > doing that would produce TITLEs that are "a
> > bit nicer". An opinion as worthy as another
> > perhaps, but "I like it" is hardly a reason
> > why changing user TITLEs is preferable to
> > just leaving them well enough alone.
>
> You have an option to disable that if you don't like it.
I repeat: it's not about what I like.
It's about what the behavior should be
for TITLE. Should users have to escape
` and ' to _prevent_ their conversion to
curly quotes? Or should they have to
provide curly quotes if that's what they
really want. What are the pros & cons
to each of those approaches _for TITLE_?
> > You can say "I like curly quotes", and I can
> > say "I like straight quotes". Opinions.
>
> The way Emacs deals with different opinions is to have user options.
> We have one here, so please customize your sessions to your liking,
> and let's stop these futile disputes.
You elided the text that followed that,
which made clear that the point is that
this is NOT about personal opinions or
preferences for personal use. You even
elided the reference to "Goûts et
couleurs", which (explained earlier) is
an expression saying that it makes no
sense to argue about personal tastes.
This is not about personal taste. I
repeat the text you elided:
[T]he real issue is leaving TITLEs up
to users. Users are perfectly capable
of deciding what _they_ prefer for
their TITLEs.
Why not leave TITLE alone, since (if) it
can be any text with any meaning for any
reason?
Note that Mauro asked similar questions
about other parts of this thread, e.g.,
Thinking about it, why do we need to call
substitute-command-keys on the VALUE part
(i.e., the cdr of the cons cell), in case
of simple item definitions?
And Steve was the first to raise the TITLE
question:
when I enter e.g. `0' at the "Title: "
prompt in the minibuffer, it displays
"Use '1'", i.e., with curve-quoting.
But if I omit the call to
substitute-command-keys on the cdr in
widget-choose, then typing `0' at the
"Title: " prompt displays "Use `1'",
i.e. with grave-quoting. But I don't
know which one is the intended result.
And Ola and Steve agreed that it makes no
sense to curly-quote the cdr (choice
return value). But they also agreed that
TITLE should use curly quotes.
IOW, different parts of this thread led
to discussion of curly-quoting specific
things. My comments were only wrt TITLE.
The only reason given, AFAICT, was by
Steve: "since the title is simply a
display feature". That reason isn't
clear, to me.
Steve followed that by saying that it
wouldn't make much difference because
existing uses of TITLE don't use quotes.
He said that curling quotes in TITLE
"might be relevant for third party use
or future uses in Emacs, as well as for
ad-hoc uses of simple item definitions."
That's true, and that's the point of
my question: Why suppose it's better
(e.g. for 3rd-party or future use) to
curl any straight quotes used in TITLE?
No answer to that, AFAICT.
The conclusion given doesn't follow,
IMO: "So applying substition to all
uses of TITLE seems appropriate."
Why would it be appropriate?
And Mauro asked a similar question to
my "Why?":
What would be a real-life scenario where
we need to use substitute-command-keys
on TITLE? I can't think of any.
Maybe he meant substitute-command-keys
as opposed to substitute-quotes; dunno.
My question is why use either - why
curl quotes in TITLE at all? I don't
ask for a real-life scenario where that
might be helpful. I ask why doing that
_systematically_, automatically, is a
good idea?
Steve agreed he can't think of a good
example where substitute-command-keys
is needed for TITLE. He ended with
"Unless some undesirable consequence of
applying substitute-command-keys to
TITLE is found, I don't see any harm in
allowing such uses."
Mauro then voted for not adding quote
conversion "until it's really needed" -
"I'd leave it out". He suggested that
it be left to a maintainer to decide.
Steve then agreed to "leaving TITLE
alone for now" and leaving it up to a
maintainer. Mauro replied "Let's wait
then."
That's when Stefan chimed in with his
suggestion to curl quotes in TITLE,
his reason being that it would "make
it look a bit nicer".
That's when I chimed in to say that
it won't necessarily look nicer or
otherwise be appropriate, because
TITLE can contain any text at all.
Still true, AFAIK. But then again,
no one has spoken to that. What are
the expectation wrt what users might
use in TITLE?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 16:34:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 64046 <at> debbugs.gnu.org (full text, mbox):
> > > > Do you have an example of where it's not? I can't think of one, so
> > > > you'll have to help me here.
> > >
> > > Don't need one. The TITLE can be _any_ text.
> > > Who knows how ` and ' might be used? You don't,
> > > any more than I do. Or if you do, please let us
> > > know your assumptions about this: what gives you
> > > the idea that they should always be translated
> > > to curly quotes?
> >
> > I was convinced by Stephen Berman's arguments upthread. He spoke
> > about the specifics of this function, how it might typically be used,
> > and used examples to show why using curly quotes is a good idea here.
> >
> > The reality is that we have decided to use curly quotes in Emacs, in
> > places where it is typographically correct. That decision was made
> > before I was very active in the project, BTW. So either we reverse
> > that decision, or we try to be consistent about it. My position is
> > that the latter is preferable.
>
> No, we will not reverse that decision.
Straw man. No one asked to reverse the
decision "to use curly quotes in Emacs, in
places where it is typographically correct."
No such generalization occurred anywhere in
this bug thread.
> Conversion of quotes is
> dynamic, it's sensitive to the display capabilities of the underlying
> terminal, and includes enough knobs for people who don't want that to
> disable it. I wish that Drew had finally accepted this as a fait
> accompli and stopped raising the same arguments on every opportunity.
I raised no arguments here against using
curly quotes in doc and help. I raised
no arguments here even against using them
in the general context of "Quoting in
customize choice tags" (this thread).
I raised the question _only_ wrt TITLE.
Please stop with the ad hominem argument.
The question of curly quotes in TITLE is
not about me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 23:30:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Fri, 1 Sep 2023 16:17:58 +0000 Drew Adams <drew.adams <at> oracle.com> wrote:
[...]
> IOW, different parts of this thread led
> to discussion of curly-quoting specific
> things. My comments were only wrt TITLE.
> The only reason given, AFAICT, was by
> Steve: "since the title is simply a
> display feature". That reason isn't
> clear, to me.
According to the doc string of widget-choose, the TITLE argument "is the
name of the list" from which an item is chosen. I know of three types
of specific uses of TITLE, two in the Customize UI: the title or name of
the Value mene (hard-coded as "Choice") and the title or name of the
State menu (hard-coded as "Operation on <option name>")), and in simple
item definitions, where it is the prompt for entering the number of the
chosen item in the minibuffer. I can't think of any function these uses
have besides displaying information; can you?
> Steve followed that by saying that it
> wouldn't make much difference because
> existing uses of TITLE don't use quotes.
> He said that curling quotes in TITLE
> "might be relevant for third party use
> or future uses in Emacs, as well as for
> ad-hoc uses of simple item definitions."
>
> That's true, and that's the point of
> my question: Why suppose it's better
> (e.g. for 3rd-party or future use) to
> curl any straight quotes used in TITLE?
> No answer to that, AFAICT.
The answer is for consistency with the handling of quotes (and
potentially other display features that substitute-command-keys applies
to) in the display of items in uses of widget-choose. That was the
reason for my OP in this bug report; at that time I hadn't given any
thought to the TITLE argument, nor to simple item definitions, but after
Ola Nilsson drew attention to both, it seemed plausible to me to treat
TITLE like the items.
> The conclusion given doesn't follow,
> IMO: "So applying substition to all
> uses of TITLE seems appropriate."
>
> Why would it be appropriate?
Here I meant by "all uses of TITLE" both the simple item definitions and
the key menu definitions used by the Customize UI; i.e., that the
handling of TITLE should apply to all these types.
[...]
> My question is why use either - why
> curl quotes in TITLE at all? I don't
> ask for a real-life scenario where that
> might be helpful. I ask why doing that
> _systematically_, automatically, is a
> good idea?
Again, for consistency with the rest of the UI provided by
widget-choose. It's automatic only by default, since the realization of
quote substitution is customizable.
> Steve agreed he can't think of a good
> example where substitute-command-keys
> is needed for TITLE. He ended with
> "Unless some undesirable consequence of
> applying substitute-command-keys to
> TITLE is found, I don't see any harm in
> allowing such uses."
Do you know of any undesirable consequences? An apparent problem is
when TITLE contains several occurrences of the same kind of quote that
one wants to display in different ways, e.g. in "Type ``' or `''", where
you may want the first and third occurrences of ` and ', respectively,
to be displayed in curve-style, and the second occurrence of each of
these in grave-style. But with substitute-command-keys this is
possible:
(substitute-command-keys "Type `\\=`' or `\\=''")
(With substitute-quotes, however, using the \\= escape does not work.)
Given that, I don't see how using substitute-command-keys on the TITLE
argument in widget-choose restricts any use of this argument.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Fri, 01 Sep 2023 23:39:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> (With substitute-quotes, however, using the \\= escape does not work.)
Hmm, that seems like an oversight by the author of `substitute-quotes'.
> Given that, I don't see how using substitute-command-keys on the TITLE
> argument in widget-choose restricts any use of this argument.
Yup. So let's get this installed.
What's the most recent version of your patch, did you already send it? Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 02 Sep 2023 02:13:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 64046 <at> debbugs.gnu.org (full text, mbox):
I won't repeat what I've already said in more
detail. I'll just say this much again: TITLE
can presumably be any text whatsoever.
There's nothing that suggests that `...', let
alone any other uses of ` or ', correspond to
the uses for which we've replaced `...' with
curly quotes. Nothing.
If it ain't broke, don't "fix" it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 02 Sep 2023 09:50:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2 Sep 2023 01:38:03 +0200 Stefan Kangas <stefankangas <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> (With substitute-quotes, however, using the \\= escape does not work.)
>
> Hmm, that seems like an oversight by the author of `substitute-quotes'.
>
>> Given that, I don't see how using substitute-command-keys on the TITLE
>> argument in widget-choose restricts any use of this argument.
>
> Yup. So let's get this installed.
>
> What's the most recent version of your patch, did you already send it? Thanks.
It's in <87r0nnmg31.fsf <at> gmx.net>
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-08/msg02199.html).
Before installing it should I remove the word "quote" from the comment
"Apply quote substitution to choice menu title and item text", since
substitute-command-keys also does other substitutions?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 02 Sep 2023 19:00:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 64046 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> It's in <87r0nnmg31.fsf <at> gmx.net>
> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-08/msg02199.html).
OK, LGTM with your proposed fix:
> Before installing it should I remove the word "quote" from the comment
> "Apply quote substitution to choice menu title and item text", since
> substitute-command-keys also does other substitutions?
So please do that and then install. Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#64046; Package
emacs.
(Sat, 02 Sep 2023 21:26:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 64046 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2 Sep 2023 11:59:28 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> It's in <87r0nnmg31.fsf <at> gmx.net>
>> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-08/msg02199.html).
>
> OK, LGTM with your proposed fix:
>
>> Before installing it should I remove the word "quote" from the comment
>> "Apply quote substitution to choice menu title and item text", since
>> substitute-command-keys also does other substitutions?
>
> So please do that and then install. Thanks in advance.
Done in commit 088fec0a1f8 to master. Thanks.
Steve Berman
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 01 Oct 2023 11:24:18 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.