How to opt out of curly-quote spamming altogether?

How to opt out of curly-quote spamming altogether?

[Drew Adams]

Could someone please remind me how to completely turn OFF the
aberrant and ubiquitous curly-quote virus?

(I have `electric-quote-mode' OFF, but that does not help with
existing doc etc.)

Even just to paste text from the manuals into an Emacs
StackExchange question or answer I now need to manually change
each pasted curly quote into a backtick, in order to get SE's
own code-inline highlighting (`...`).  (Previously I needed to
change only the apostrophe of `...' into a backtick.)

Naturally, I looked in NEWS for an option or mode, to turn this
OFF.  But naturally, NEWS is not yet fully written for this
"feature" (it likely will not be fully written until soon before
the release).

NEWS does mention, misleadingly, the "New minor mode
electric-quote-mode for quoting 'like this' and "like this"" -
as if turning that mode off would eliminate such quotation.
Presumably the final wording will make clear that, per the doc
string, this mode is only about "replacing [classic quoting]
with [curly-quoting] _as you type_".

There are at least 4 locations in NEWS where the new curly-quoting
is advertised, but I found nothing that tells me clearly how to
opt out of its spamming altogether.

I did find, buried in the NEWS entry "substitute-command-keys
now replaces quotes", mention of option `help-quote-translation',
whose doc string gives the impression that simply changing the
value will change the quote-style behavior: "Left and right quotes
are determined by new custom variable 'help-quote-translation'.
(This should not be only under a `substitute-command-keys' entry.)

But that is apparently not the case in general.  AFAICT, that
option has no effect on the quotation style used in the manuals.
They still show curly quotes, even though the option value is
now 96.  (As I said previously, the option values should not be
characters, which are shown to users as integers.  They should
be meaningful, easy to recognize strings or symbols.)

`help-quote-translation' does seem to prevent curly quotes in
*Help* buffers, so at least there's that.  But I'm looking for
a switch to turn this virus OFF everywhere - to return to
Classic Emacs.  Surely such a simple ON/OFF switch exists?
Perhaps info about it was buried in some of the voluminous
missives back and forth here, but a simple reminder would be
greatly appreciated.  Thank you.

Re: How to opt out of curly-quote spamming altogether?

[Eli Zaretskii]

> Date: Sun, 23 Aug 2015 21:16:18 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> `help-quote-translation' does seem to prevent curly quotes in
> *Help* buffers, so at least there's that.  But I'm looking for
> a switch to turn this virus OFF everywhere - to return to
> Classic Emacs.  Surely such a simple ON/OFF switch exists?

It doesn't.  What you see in Info is literal characters generated when
the documentation is built during the Emacs build process.  So, to
change that, you will have to regenerate the documentation, telling
makeinfo not to produce Unicode characters there.

Alternatively, you can set up your standard-display-table to display
those characters as their ASCII equivalents.

Re: How to opt out of curly-quote spamming altogether?

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Drew Adams wrote:
> Presumably the final wording will make clear that, per the doc
> string, this mode is only about "replacing [classic quoting]
> with [curly-quoting] _as you type_".

Thanks, done in master with the attached patch.

> (This should not be only under a `substitute-command-keys' entry.)

Also done with the attached patch.

> that option has no effect on the quotation style used in the manuals.

Correct.  Display of info files is unaffected by the changes in Emacs master 
over the past month or two.  Info files use curved quotes as of Emacs 24.5, due 
to a 2013 change in Texinfo, not in Emacs.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-etc-NEWS-Clarify-text-quoting-style-and-electric-quo.patch --]
[-- Type: text/x-diff; name="0001-etc-NEWS-Clarify-text-quoting-style-and-electric-quo.patch", Size: 1976 bytes --]

From 726bf1239d9fadf9e808394831e9a5059f8460fd Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 24 Aug 2015 08:19:41 -0700
Subject: [PATCH] * etc/NEWS: Clarify text-quoting-style and
 electric-quote-mode.

---
 etc/NEWS | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 90a13b7..fd2ed4d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -271,7 +271,8 @@ successive char insertions.
 ** C-x 8 now has shorthands for these chars: ‐ ‑ ‒ – — ― ‘ ’ “ ” † ‡ • ′ ″
 € № ← → ↔ − ≈ ≠ ≤ ≥.  As before, you can type C-x 8 C-h to list shorthands.
 
-** New minor mode electric-quote-mode for quoting ‘like this’ and “like this”.
+** New minor mode electric-quote-mode for quoting ‘like this’ and “like this”
+as you type.
 
 ** New minor mode global-eldoc-mode is enabled by default.
 
@@ -910,8 +911,16 @@ denied" instead of "permission denied".  The old behavior was problematic
 in languages like German where downcasing rules depend on grammar.
 
 +++
+** New variable ‘text-quoting-style’ to control how Emacs translates quotes.
+Set it to ‘curve’ for curved single quotes ‘like this’, to ‘straight’
+for straight apostrophes 'like this', and to ‘grave’ for grave accent
+and apostrophe `like this'.  The default value nil acts like ‘curve’
+if curved single quotes are displayable, and like ‘grave’ otherwise.
+Quotes in info files are not translated.
+
++++
 ** substitute-command-keys now replaces quotes.
-That is, it converts documentation strings' quoting style as per the
+That is, it converts documentation strings’ quoting style as per the
 value of ‘text-quoting-style’.  Doc strings in source code can use
 either curved quotes or grave accent and apostrophe.  As before,
 isolated apostrophes and characters preceded by \= are output as-is.
-- 
2.1.0

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > `help-quote-translation' does seem to prevent curly quotes in
> > *Help* buffers, so at least there's that.  But I'm looking for
> > a switch to turn this virus OFF everywhere - to return to
> > Classic Emacs.  Surely such a simple ON/OFF switch exists?
> 
> It doesn't.  What you see in Info is literal characters generated
> when the documentation is built during the Emacs build process.
> So, to change that, you will have to regenerate the documentation, 
> telling makeinfo not to produce Unicode characters there.
> 
> Alternatively, you can set up your standard-display-table to display
> those characters as their ASCII equivalents.

That's horrible.  Users should be able to control this, easily.

I don't see this problem in a Windows binary from 2014-11-30.  The
regression was apparently introduced to the Windows builds between
then and 2014-12-29.

It sounds like this is a makeinfo build-time configuration decision.
In that case, can Emacs please provide doc produced both ways, and
let users choose the appearance they want?  At least please make the
non-curlified doc available as a separate download, with releases.

Both doc alternatives could be separate downloads, with Emacs
imposing no prejudice wrt bundling.  The download site could also
let users choose which they want, and automatically download both
the code tarball sans doc and the chosen doc format.

A display-table hack would presumably change all uses of a curly
quote.  That's not appropriate - it is only the code-"quoting"
uses that need to be changable/configurable by a user.  And if
this is not really a problem then please provide users with a
runtime choice, which fiddles with the display table as needed.

Code-"quoting" (inline code display) is a final presentation
thing.  It should not be, in effect, hardcoded.

If Texinfo/makeinfo is as inflexible as you suggest, maybe it
really is time to move to XML/HTML with XSLT/CSS.  Presentation
should be separated from content/structure, and that is apparently
not the case now.  There should be some flexibility in how a given
semantic construct, such as inline code, is finally presented.

There has been a lot of noise about "modernizing" Emacs's
appearance, behind the move to use curly quotes.  Modernizing
Emacs's appearance, including its doc, should first of all mean
separating out presentation from content/structure.  Whether the
fault for this regression is with Texinfo/makeinf or Emacs core
code changes, this "modernization" puts the cart before the
horse, and is a step backward for users.

Re: How to opt out of curly-quote spamming altogether?

[Eli Zaretskii]

> Date: Mon, 24 Aug 2015 09:34:09 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > > `help-quote-translation' does seem to prevent curly quotes in
> > > *Help* buffers, so at least there's that.  But I'm looking for
> > > a switch to turn this virus OFF everywhere - to return to
> > > Classic Emacs.  Surely such a simple ON/OFF switch exists?
> > 
> > It doesn't.  What you see in Info is literal characters generated
> > when the documentation is built during the Emacs build process.
> > So, to change that, you will have to regenerate the documentation, 
> > telling makeinfo not to produce Unicode characters there.
> > 
> > Alternatively, you can set up your standard-display-table to display
> > those characters as their ASCII equivalents.
> 
> That's horrible.  Users should be able to control this, easily.

Why?  We don't have easy controls for displaying one character as
another.  Why should these characters be different?

> I don't see this problem in a Windows binary from 2014-11-30.  The
> regression was apparently introduced to the Windows builds between
> then and 2014-12-29.

It's the question of which version of Texinfo was used for producing
the docs.  The defaults in Texinfo changed recently, independently of
Emacs development.

> A display-table hack would presumably change all uses of a curly
> quote.

A display table can be specific to a buffer or a window.  See the
ELisp manual for more about that.

But it was you that asked for a switch that changed them _everywhere_,
which is why I suggested standard-display-table, which is global.

> That's not appropriate - it is only the code-"quoting"
> uses that need to be changable/configurable by a user.

What is "code-'quoting'"?  An Info manual is not code, it's mostly
text, but you still wanted these characters changed there.

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > That's horrible.  Users should be able to control this, easily.
> 
> Why?  We don't have easy controls for displaying one character as
> another.  Why should these characters be different?

This is not about "displaying one character as another."  It is
about choosing how to present inline code fragments.  It is not
about substituting for literal curly quotes everwhere, as I made
clear.

> > I don't see this problem in a Windows binary from 2014-11-30.  The
> > regression was apparently introduced to the Windows builds between
> > then and 2014-12-29.
> 
> It's the question of which version of Texinfo was used for producing
> the docs.  The defaults in Texinfo changed recently, independently
> of Emacs development.

Defaults?  So Emacs has a choice?

> > A display-table hack would presumably change all uses of a curly
> > quote.
> 
> A display table can be specific to a buffer or a window.  See the
> ELisp manual for more about that.

I don't see how that would help anyone.  It's too late, once the
curly quotes are hard-coded in the output.  There is no reasonable
way for a user at that point to tell Emacs which occurrences
represent presentation of inline code and which really belong
as literal curly quotes.

> But it was you that asked for a switch that changed them
> _everywhere_, which is why I suggested standard-display-table,
> which is global.

Disingenuous.  You know full well what I'm talking about: undoing
the use of curly quotes to replace `...'.  And yes, that everywhere.
But certainly not _replacing_ all occurrences of curly quotes,
including any that have nothing to do with inline code (`...').

> > That's not appropriate - it is only the code-"quoting"
> > uses that need to be changable/configurable by a user.
> 
> What is "code-'quoting'"?  An Info manual is not code, it's mostly
> text, but you still wanted these characters changed there.

The use of `...' has primarily been to set off inline code fragments
from the surrounding text.

It has also been used sometimes for URLs, file names, and some links,
but those uses are arguably inappropriate.  Use whatever phrase you
like, but you know, I think, that I am referring to the replacement
of `...' by wrapping with curly quotes, and only that.

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > that option has no effect on the quotation style used in the
> > manuals.
> 
> Correct.  Display of info files is unaffected by the changes in
> Emacs master over the past month or two.  Info files use curved
> quotes as of Emacs 24.5, due to a 2013 change in Texinfo, not in Emacs.

Not good.  Users should have control over this, or the previous
behavior should be restored.

It makes no sense for Emacs to impose curly quoting for inline code
fragments.  That doesn't make much sense for other programming
contexts either.  Why should Texinfo make such decisions about the
doc for a particular product such as Emacs?  This is truly a step
backward.

Wrt the argument that a 2013 Texinfo change forces Emacs's hand:
I have Emacs builds that are much more recent than 2013, and which
do not exhibit this breakage.  Sounds to me like a cop-out, to
blame this only on a Texinfo change.

Hard to believe that Texinfo/makeinfo does not give builders any
choice about the resulting characters.  And Eli seems to make clear
that Emacs _can_ still be built without curly quotes, "telling
makeinfo not to produce Unicode characters there".

If nothing else works, the doc should be built both ways, and users
should be allowed to choose which presentation to use.

Re: How to opt out of curly-quote spamming altogether?

[Paul Eggert]

Drew Adams wrote:
> In that case, can Emacs please provide doc produced both ways, and
> let users choose the appearance they want?

That would make for more complexity and size in maintenance, distribution and 
installation, for little benefit to most users.

With either the old or the new info quoting styles you need to translate quotes 
when copying to StackExchange, so I suggest writing a bit of specialized Elisp 
code to translate these quotes exactly the way you like.

Re: How to opt out of curly-quote spamming altogether?

[Eli Zaretskii]

> Date: Mon, 24 Aug 2015 10:06:31 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > > That's horrible.  Users should be able to control this, easily.
> > 
> > Why?  We don't have easy controls for displaying one character as
> > another.  Why should these characters be different?
> 
> This is not about "displaying one character as another."  It is
> about choosing how to present inline code fragments.

But an Info manual uses the quotes not only in code fragments, it uses
them, for example, when defining new terminology and when describing
keyboard input.

> It is not about substituting for literal curly quotes everwhere, as
> I made clear.

I'm sorry, but nothing is clear about what you described.

I should probably stop replying, as my attempt at helping you is
quickly slipping into another annoying discussion, where you hold me
responsible for some crime I didn't commit.

> > > I don't see this problem in a Windows binary from 2014-11-30.  The
> > > regression was apparently introduced to the Windows builds between
> > > then and 2014-12-29.
> > 
> > It's the question of which version of Texinfo was used for producing
> > the docs.  The defaults in Texinfo changed recently, independently
> > of Emacs development.
> 
> Defaults?  So Emacs has a choice?

_Texinfo_ defaults.  Not _Emacs_ defaults.

> > > A display-table hack would presumably change all uses of a curly
> > > quote.
> > 
> > A display table can be specific to a buffer or a window.  See the
> > ELisp manual for more about that.
> 
> I don't see how that would help anyone.  It's too late, once the
> curly quotes are hard-coded in the output.  There is no reasonable
> way for a user at that point to tell Emacs which occurrences
> represent presentation of inline code and which really belong
> as literal curly quotes.

That's what I said to begin with, didn't I?

> > But it was you that asked for a switch that changed them
> > _everywhere_, which is why I suggested standard-display-table,
> > which is global.
> 
> Disingenuous.  You know full well what I'm talking about

Actually, no, I don't.

> > What is "code-'quoting'"?  An Info manual is not code, it's mostly
> > text, but you still wanted these characters changed there.
> 
> The use of `...' has primarily been to set off inline code fragments
> from the surrounding text.
> 
> It has also been used sometimes for URLs, file names, and some links,
> but those uses are arguably inappropriate.

And I was supposed to guess what is and isn't appropriate how?
Shouldn't you have explained that to begin with, instead of getting
mad at my "dis-ingenuity"?

> Use whatever phrase you like, but you know, I think, that I am
> referring to the replacement of `...' by wrapping with curly quotes,
> and only that.

Even that is used for more than just code snippets.

Anyway, I'm outta here.

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > In that case, can Emacs please provide doc produced both ways, and
> > let users choose the appearance they want?
> 
> That would make for more complexity and size in maintenance,
> distribution and installation, for little benefit to most users.

You decide how much benefit it is to users?  How about letting
them decide, themselves?  Give them the choice, please.

> With either the old or the new info quoting styles you need to
> translate quotes when copying to StackExchange, so I suggest
> writing a bit of specialized Elisp code to translate these quotes
> exactly the way you like.

Not interested.  And no, I don't use Emacs for this.  I will
continue to manually copy and paste, even if curly quotes make
the quote-mark fixup twice the effort.

I typically provide a link to the appropriate node in the online
(HTML) manual, and I quote a portion of the text from that node in
the post.  Had Emacs chosen `...` instead of curly quotes, as Andreas
suggested several times (likely tongue-in-cheek), there would be
no change needed.

And had Emacs left its classic `...' in place, there would be only
half as many quote changes needed.  I will make such changes, but
I doubt if many other SE users will bother to.  The result will be
that inline code will *not* be set off as different from ordinary
text in such posts.  Emacs doc will look worse in this context, and
more importantly, code fragments (function names and such) will
not stand out at all, detracting from reader understanding.

But this is a minor point.  The real point in this connection
is that such setting-off of inline code fragments is semantic.

Different systems use different syntax/techniques to do it.
Choosing curly quotes for this is about the worst thing Emacs
could do - they are used pretty much nowhere for this purpose,
and for good reason: curly quotes quote ordinary text.  They are
not a good vehicle for setting off inline code.

This is the case whether you realize it now or not.  The question
is not just one of looking "modern" by showing that Emacs too can
use curly quotes.  That's a sad attempt to show how "modern" Emacs
is, I'm afraid.  Emacs will get no converts because the "retro look"
of `...' is replaced by the "modern" curly-quoting of inline code.

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > This is not about "displaying one character as another."  It is
> > about choosing how to present inline code fragments.
> 
> But an Info manual uses the quotes not only in code fragments, it
> uses them, for example, when defining new terminology and when
> describing keyboard input.

Yes, and none of those uses have anything to do with the use of a
curly quote to represent _itself_.  They are all cases of what I have
been calling "setting off inline code".  In other doc systems they
would have an underlying markup (e.g., XML element) that distinguishes
them, structurally, from ordinary text.  And typically they would not
just all use the same markup/element: code would use, say, <Code>,
new terminology would use, say, <GlossaryTerm>, and so on.

But whether they all are represented structurally/semantically the
same way or not, they perform the task of setting off their contents
semantically.  They cannot be confused with ordinary text.

And then there is how these semantic critters are presented finally.
Typically, presentation is a separate layer or process, and the
same structure/content can be, by choice, presented in different
ways (for different media, among other things).  Inline code is
typically presented using a fixed-width font, such as Courier, as
opposed to ordinary text, which is typically presented using a
proportional font.  Glossary terms might be presented using bold
or colored text, perhaps linked to a glossary entry.  And so on.

Anyone used to LaTeX or Tex is used to this separation, for example.
I'm surprised if Texinfo/makeinfo does not provide for it - if an
inline code snippet or key binding necessarily ends up with a
presentation that is identical to ordinary text quoting (curly
quotes, whether single or double).
 
> > It is not about substituting for literal curly quotes everwhere,
> > as I made clear.
> 
> I'm sorry, but nothing is clear about what you described.

Maybe you're not trying to understand?

> I should probably stop replying, as my attempt at helping you is
> quickly slipping into another annoying discussion, where you hold me
> responsible for some crime I didn't commit.

There's no crime, only a regression for users. I cannot say who or
what is responsible, nor does it matter what I think about that.
It may be tools (e.g. Texinfo) that are responsible.  It may be
changes implemented recently - or both.

For users, things have gone downhill, IMHO.  What was a pretty
clear separation of code (and keys and URLs etc.) from the
surrounding text has been lost.  Some people don't like the retro
look of `...', but that's not really the point.  I would be happy
if some other, straightforward, easy-to-use means were adopted for
setting off such thingies from the surrounding text.

But note that Emacs doc is not used _only_ the way other doc is used.
There is a lot more search etc. going on, which means that if Emacs
were to, for example, set inline code off using a fixed-width font
then we would need an easy way to search for such bits, search within
such bits, and search outside of such bits.  That's doable, but not
done so far.

Instead, we've got only curly quotation to set things off, and that
is a very poor substitute for `...' (for Emacs) or for a fixed-width
font (for other docs).

> > > It's the question of which version of Texinfo was used for
> > > producing the docs.  The defaults in Texinfo changed recently,
> > > independently of Emacs development.
> >
> > Defaults?  So Emacs has a choice?
> 
> _Texinfo_ defaults.  Not _Emacs_ defaults.

If they are Texinfo _defaults_ then doesn't that mean that Texinfo
also provides other choices?  If not then how are they just defaults?

Re: How to opt out of curly-quote spamming altogether?

[Eli Zaretskii]

> Date: Mon, 24 Aug 2015 10:57:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > > It is not about substituting for literal curly quotes everwhere,
> > > as I made clear.
> > 
> > I'm sorry, but nothing is clear about what you described.
> 
> Maybe you're not trying to understand?

Like I said:

> > I should probably stop replying, as my attempt at helping you is
> > quickly slipping into another annoying discussion, where you hold me
> > responsible for some crime I didn't commit.
> > > > It's the question of which version of Texinfo was used for
> > > > producing the docs.  The defaults in Texinfo changed recently,
> > > > independently of Emacs development.
> > >
> > > Defaults?  So Emacs has a choice?
> > 
> > _Texinfo_ defaults.  Not _Emacs_ defaults.
> 
> If they are Texinfo _defaults_ then doesn't that mean that Texinfo
> also provides other choices?

Yes, it does.  As I already said a few messages ago.

Re: How to opt out of curly-quote spamming altogether?

[David Kastrup]

Drew Adams <drew.adams@oracle.com> writes:

> Typically, presentation is a separate layer or process, and the
> same structure/content can be, by choice, presented in different
> ways (for different media, among other things).  Inline code is
> typically presented using a fixed-width font, such as Courier, as
> opposed to ordinary text, which is typically presented using a
> proportional font.  Glossary terms might be presented using bold
> or colored text, perhaps linked to a glossary entry.  And so on.
>
> Anyone used to LaTeX or Tex is used to this separation, for example.

That's an interesting statement since plain TeX does not in any manner
provide semantic commands (it switches to a typewriter font when using
verbatim but the reason for that is quite banally that normal text fonts
are not able to print all ASCII characters as they use, say, text quotes
instead of ` and ' characters and some other, more glaring
substitutions).

Plain TeX does not even have an \em command for emphasizing things.  You
need to decide yourself whether to use italics or boldface or
underlining or whatever.

LaTeX tries to be a bit more semantic, but the sort of differentiation
that Texinfo requires would require loading quite a number of non-core
packages.

> I'm surprised if Texinfo/makeinfo does not provide for it - if an
> inline code snippet or key binding necessarily ends up with a
> presentation that is identical to ordinary text quoting (curly quotes,
> whether single or double).

Texinfo is primarily semantic markup.  Various backends decide how to
typeset things.  In its text mode, plain TeX as well as texinfo.tex
convert ` and ' characters into proper English symmetric quote marks
(the respective default _text_ fonts do not have a straight quote mark
or a backquote in their corresponding character slots).  The proper
representation in Unicode is the use of the English ‘quote marks’: those
are the proper characters for the glyphs TeX and Texinfo use for text
fonts in the slots for ` and '.  Consequently, it is quite correct that
those are the output for the preformatted Info pages.

> There's no crime, only a regression for users. I cannot say who or
> what is responsible, nor does it matter what I think about that.

Indeed.  Most particularly since you are late to the game, do not bother
with getting yourself acquainted with the matter at hand and vent in the
wrong place.

This is done by Texinfo already when generating Info.  I think that at
some point in the past, it was Emacs as Info viewer which converted `'
into curved quotes, but that obviously had to be based on heuristics and
was unreliable.  In contrast, a Drew-mode converting ‘’ back into `'
should be able to do its job unambiguously.  There has not been much of
an interest expressed elsewhere, so it's likely up to you to program it.

Or complain to the Texinfo developer list in your signature style.

Good luck.

-- 
David Kastrup

Re: How to opt out of curly-quote spamming altogether?

[Paul Eggert]

Drew Adams wrote:
> You decide how much benefit it is to users?  How about letting
> them decide, themselves?

You can rebuild the Info files yourself, using Texinfo 4 or with some Texinfo 5 
option that I don't recall offhand.  So you have a choice.

Shipping two versions of Emacs, or even two versions of the info files, would 
complicate things for maintainers and distributors and users, and this burden 
would outweigh any minor benefit.

RE: How to opt out of curly-quote spamming altogether?

[Drew Adams]

> > Typically, presentation is a separate layer or process, and the
> > same structure/content can be, by choice, presented in different
> > ways (for different media, among other things).  Inline code is
> > typically presented using a fixed-width font, such as Courier, as
> > opposed to ordinary text, which is typically presented using a
> > proportional font.  Glossary terms might be presented using bold
> > or colored text, perhaps linked to a glossary entry.  And so on.
> >
> > Anyone used to LaTeX or Tex is used to this separation, for
> > example.
> 
> That's an interesting statement since plain TeX does not in any
> manner provide semantic commands (it switches to a typewriter font when
> using verbatim but the reason for that is quite banally that normal text
> fonts are not able to print all ASCII characters as they use, say, text
> quotes instead of ` and ' characters and some other, more glaring
> substitutions).
> 
> Plain TeX does not even have an \em command for emphasizing things.
> You need to decide yourself whether to use italics or boldface or
> underlining or whatever.

Sorry, I should have stuck with LaTeX as the example.  It is LaTeX
that I am (used to be, many moon ago) familiar with (as a user only).

> LaTeX tries to be a bit more semantic, but the sort of differentiation
> that Texinfo requires would require loading quite a number of non-
> core packages.

I didn't mean to suggest that we should use LaTeX (or Tex) - I hadn't
considered that.  I meant it only as an example, which I thought some
people here might be familiar with, of separation of presentation from
structure.

A better example is XML-based doc.  The structure is what it is, and
you can render/present it in any number of ways.  Likewise, HTML.

> > I'm surprised if Texinfo/makeinfo does not provide for it - if an
> > inline code snippet or key binding necessarily ends up with a
> > presentation that is identical to ordinary text quoting (curly
> > quotes, whether single or double).
> 
> Texinfo is primarily semantic markup.  Various backends decide how
> to typeset things.

That's what I thought.  And makeinfo is what creates the Info
presentation we use.  But I have only a vague idea of these things.

> In its text mode, plain TeX as well as texinfo.tex convert ` and '
> characters into proper English symmetric quote marks (the respective
> default _text_ fonts do not have a straight quote mark or a backquote
> in their corresponding character slots).  

OK, but that is not really the point here.  The point is that the
pre-presentation way we represent inline code (or URLs or emphasis
or whatever structural/semantic elements) would/should ideally not be
` and ' (or curly quotes, a fortiori).  Why?  For the reason that Paul
and others (I think) and I have given: you can't tell when ` and ' are
used as markup (for structure) vs representing just themselves as chars.

In most doc contexts, some kind of nonambiguous element or markup is
used to identify its argument text as of a particular kind (e.g. code).

But in Emacs, it is useful to have the representation of the structure
be something that users can directly search etc.  And it is useful if
it can be readable enough to serve more or less for presentation.  IOW,
any presentation-layer transformation should be kept small/minor, to be
able to take advantage of Emacs's ability to manipulate the plain-text
input (structure/content layer).  IOW, if possible, we don't really
want to be looking at, searching, etc., XML elements or similar.

And in that context, I personally think that `...' is a reasonable
(nearly brilliant) compromise.  We could throw some presentation on
top of it - I'm not against that.  But what we should not do, IMO, is
either (a) just replace it by curly-quote chars or (b) render it, as
presentation, using curly-quote chars.

(a) is because of the PITA of typing etc. such chars, but this is a
minor problem compared with (b), I think.  (b) is important, to me,
because curly quotes are used for ordinary text quoting.  Any char
should be allowed to represent itself.  The problems with ` and '
doing that apply also to curly quotes.  And curly quotes also have
a day job of quoting ordinary text, unlike ` and '.

I would rather have us use, say, highlighting, or a different font,
to set off such pieces of text (e.g. inline code), than to show
them as if they were ordinary quoted text.

But then, if we rendered inline code, URLs etc. by highlighting
the text or using a different font, how to search for or within or
outside such zones of text?

That could be implemented.  I have code that lets you search
within or outside of zones of text that have particular text
properties, for example, or are delimited using buffer positions
(e.g. markers).  And the same thing could be done for text zones
with a particular font (I have not done that, so far).

I'm not saying that we need to do something like this.  I'm saying
that this is preferable to a rendering/presentation that just
muddies the water by using ordinary text quoting (curly quotes).
We can do better - but not if we give up at the start and adopt
curly quotes as our markup and presentation.

Personally, I think that sticking with `...' is a reasonable
approach: simple, rarely ambiguous, supple wrt inputting the
chars, searching, etc.  But fixed-width font for such things,
and proportional font for ordinary text, would also be a
reasonable presentation.

> The proper representation in Unicode is the use of the English
> ‘quote marks’: those are the proper characters for the glyphs TeX
> and Texinfo use for text fonts in the slots for ` and '.
> Consequently, it is quite correct that those are the output for
> the preformatted Info pages.

See above.  It's not about translating ` and '.  Imagine that those
are not used in the input to start with, i.e., that we used other
markup to distinguish inline code, URLs etc.

That curly quotes are "proper representations in Unicode" of ` and '
is irrelevant.  We should not be asking how to represent ` and ',
but how to demark things like inline code fragments in a structural
layer and how to present them in a presentation layer.

Besides which, the "proper representation" of ` and ' in Unicode
is ` and '.  They are first-class Unicode citizens.

Re: How to opt out of curly-quote spamming altogether?

[David Kastrup]

Drew Adams <drew.adams@oracle.com> writes:

>> The proper representation in Unicode is the use of the English
>> ‘quote marks’: those are the proper characters for the glyphs TeX
>> and Texinfo use for text fonts in the slots for ` and '.
>> Consequently, it is quite correct that those are the output for
>> the preformatted Info pages.
>
> See above.  It's not about translating ` and '.  Imagine that those
> are not used in the input to start with, i.e., that we used other
> markup to distinguish inline code, URLs etc.
>
> That curly quotes are "proper representations in Unicode" of ` and '
> is irrelevant.  We should not be asking how to represent ` and ',
> but how to demark things like inline code fragments in a structural
> layer and how to present them in a presentation layer.
>
> Besides which, the "proper representation" of ` and ' in Unicode
> is ` and '.  They are first-class Unicode citizens.

What about “those are the proper characters for the glyphs TeX and
Texinfo use for text fonts in the slots for ` and '” did you not
understand?

-- 
David Kastrup