all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "maurooaranda@gmail.com" <maurooaranda@gmail.com>,
	"ola.x.nilsson@axis.com" <ola.x.nilsson@axis.com>,
	"stephen.berman@gmx.net" <stephen.berman@gmx.net>,
	"stefankangas@gmail.com" <stefankangas@gmail.com>,
	"64046@debbugs.gnu.org" <64046@debbugs.gnu.org>
Subject: bug#64046: 30.0.50; Quoting in customize choice tags
Date: Fri, 1 Sep 2023 16:17:58 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488BD9B4B8071E14F8DC695F3E4A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <838r9qcsfx.fsf@gnu.org>

> > > 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?





  reply	other threads:[~2023-09-01 16:17 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13 14:02 bug#64046: 30.0.50; Quoting in customize choice tags Stephen Berman
2023-06-13 15:56 ` Eli Zaretskii
2023-06-14 19:51   ` Mauro Aranda
2023-06-14 20:05   ` Mauro Aranda
2023-06-15 11:39     ` Stephen Berman
2023-06-22 20:07       ` Stephen Berman
2023-06-22 22:59         ` Mauro Aranda
2023-06-23 22:18           ` Stephen Berman
2023-06-24  6:37             ` Eli Zaretskii
2023-06-24  8:50               ` Stephen Berman
2023-07-15 13:20 ` Mauro Aranda
2023-07-20 15:48   ` Stephen Berman
2023-07-20 19:11     ` Mauro Aranda
2023-07-20 19:53       ` Stephen Berman
2023-08-21 12:04         ` Ola x Nilsson
2023-08-21 14:51           ` Mauro Aranda
2023-08-24 12:51             ` Stephen Berman
2023-08-24 13:19               ` Stephen Berman
2023-08-24 20:14                 ` Mauro Aranda
2023-08-24 20:54                   ` Stephen Berman
2023-08-24 21:58                     ` Mauro Aranda
2023-08-25  8:02                       ` Ola x Nilsson
2023-08-25 21:50                         ` Stephen Berman
2023-08-28  9:33                           ` Ola x Nilsson
2023-08-28 13:50                             ` Stephen Berman
2023-08-30 15:29                               ` Mauro Aranda
2023-08-30 16:29                                 ` Stephen Berman
2023-08-30 22:33                                   ` Mauro Aranda
2023-08-30 22:51                                     ` Stephen Berman
2023-08-30 22:58                                       ` Mauro Aranda
2023-08-31  5:41                                         ` Eli Zaretskii
2023-08-31  6:43                                           ` Stefan Kangas
2023-08-31 15:43                                             ` Drew Adams
2023-08-31 20:52                                               ` Stefan Kangas
2023-08-31 22:10                                                 ` Drew Adams
2023-08-31 22:59                                                   ` Stefan Kangas
2023-09-01  1:08                                                     ` Drew Adams
2023-09-01  6:34                                                       ` Eli Zaretskii
2023-09-01 16:17                                                         ` Drew Adams [this message]
2023-09-01 23:29                                                           ` Stephen Berman
2023-09-01 23:38                                                             ` Stefan Kangas
2023-09-02  9:49                                                               ` Stephen Berman
2023-09-02 18:59                                                                 ` Stefan Kangas
2023-09-02 21:25                                                                   ` Stephen Berman
2023-09-02  2:12                                                             ` Drew Adams
2023-09-01  6:16                                                     ` Eli Zaretskii
2023-09-01 16:32                                                       ` Drew Adams
2023-08-24 20:53                 ` Stefan Kangas
2023-08-24 21:10                   ` Stephen Berman
2023-08-24 21:14                     ` Stefan Kangas
2023-08-24 21:41                       ` Stephen Berman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488BD9B4B8071E14F8DC695F3E4A@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=64046@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=maurooaranda@gmail.com \
    --cc=ola.x.nilsson@axis.com \
    --cc=stefankangas@gmail.com \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.