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

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

bug#64046: 30.0.50; Quoting in customize choice tags


From: Stephen Berman
Subject: bug#64046: 30.0.50; Quoting in customize choice tags
Date: Sat, 02 Sep 2023 01:29:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Fri, 1 Sep 2023 16:17:58 +0000 Drew Adams <drew.adams@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





reply via email to

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