[Top][All Lists]

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

[bug #60836] Improve documentation of output-comparison operator

From: G. Branden Robinson
Subject: [bug #60836] Improve documentation of output-comparison operator
Date: Wed, 15 Jun 2022 01:41:41 -0400 (EDT)

Follow-up Comment #12, bug #60836 (project groff):

[comment #11 comment #11:]
> [comment #10 comment #10:]
> > The following commit is pending; please let me know what you think.
> Er, I failed to do that before this went to press (as commit fbdfd927
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=fbdfd927>), but I think
it's a great set of refinements and clarifications.

Thank you!

> If I had to quibble, I'd wonder whether, in a coding rather than a
typesetting context, "neutral apostrophes" is a better descriptor than "single
quotes."  Programmers are certainly more used to calling them single quotes;
and even to noncoders, either term should be understandable.  Also, as
delimiters for strings, they function semantically more as quotes than as
apostrophes.  At this point in the manual, there shouldn't be reason to worry
that users might interpret "single quotes" as U+2018 and U+2019, since it has
previously established that groff code is limited to Latin-1.

Can you open a new ticket for this quibble?

One of the reasons I'm so wedded to the term "neutral apostrophe" is that I
can use it unambiguously in any context.  Input, output, character, glyph,
prose, program, whatever--it always means U+0027.

If I say "single quotes", I have to worry about context, because there are at
least three--the ones we've identified, and possibly others.

If there is still a significant risk of confusion, I would prefer to add a
statement in the "Conventions Used in This Manual" node of our Texinfo manual
to rationalize this usage.


Reply to this item at:


Message sent via Savannah

reply via email to

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