names of ISO 8859 encodings

names of ISO 8859 encodings

[Bruno Haible]

Hi,

Commit 3ed1de0ddccb42bae4151c7225d3fddeab04ff43 should better
be reverted, IMO. The ISO organization or their *standards* can
be renamed to whatever names; what matters here is what the
*encoding* is commonly referred to.

The *encoding* names are standardized by IANA:
https://www.iana.org/assignments/character-sets/character-sets.xhtml
The first ISO 8859 encoding there has the name
  ISO-8859-1
or
  ISO_8859-1
and the first among these is the preferred MIME name. So, please,
in encoding names:
  * revert the ISO -> ISO/IEC change,
  * change the space after ISO to a dash/hyphen-minus.

Likewise (partially) for commit d5e5db91ece5955b21ae1aedc03ba1d56d3cf423.

Bruno

Re: names of ISO 8859 encodings

[Alejandro Colomar]

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

Hi Bruno,

On Sat, Dec 14, 2024 at 01:23:09AM +0100, Bruno Haible wrote:
> Hi,
> 
> Commit 3ed1de0ddccb42bae4151c7225d3fddeab04ff43 should better
> be reverted, IMO. The ISO organization or their *standards* can
> be renamed to whatever names; what matters here is what the
> *encoding* is commonly referred to.
> 
> The *encoding* names are standardized by IANA:
> https://www.iana.org/assignments/character-sets/character-sets.xhtml
> The first ISO 8859 encoding there has the name
>   ISO-8859-1
> or
>   ISO_8859-1
> and the first among these is the preferred MIME name. So, please,
> in encoding names:
>   * revert the ISO -> ISO/IEC change,
>   * change the space after ISO to a dash/hyphen-minus.
> 
> Likewise (partially) for commit d5e5db91ece5955b21ae1aedc03ba1d56d3cf423.
> 
> Bruno

I'm okay with reverting those if there's consensus.  Would you mind
CCing the interested parties (e.g., the people that requested that
change, and anybody that participated in the discussion)?

(I've CCed them now, anyway.)

Thanks!
And have a lovely night!
Alex


-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: names of ISO 8859 encodings

[G. Branden Robinson]

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

Hi Bruno & Alex,

At 2024-12-14T01:37:16+0100, Alejandro Colomar wrote:
> On Sat, Dec 14, 2024 at 01:23:09AM +0100, Bruno Haible wrote:
> > Commit 3ed1de0ddccb42bae4151c7225d3fddeab04ff43 should better
> > be reverted, IMO. The ISO organization or their *standards* can
> > be renamed to whatever names; what matters here is what the
> > *encoding* is commonly referred to.
> > 
> > The *encoding* names are standardized by IANA:
> > https://www.iana.org/assignments/character-sets/character-sets.xhtml
> > The first ISO 8859 encoding there has the name
> >   ISO-8859-1
> > or
> >   ISO_8859-1
> > and the first among these is the preferred MIME name. So, please,
> > in encoding names:
> >   * revert the ISO -> ISO/IEC change,
> >   * change the space after ISO to a dash/hyphen-minus.
> > 
> > Likewise (partially) for commit d5e5db91ece5955b21ae1aedc03ba1d56d3cf423.

Oy vey.  Helge Kreutzmann submitted a similar bug report to groff and I
was planning to make the ISO -> ISO/IEC change to its man pages.

Also your point seems more strident than clear to me as regards the
encoding name.  If I want to refer to character encoding _not_ in the
context of a machine-parsed MIME datum, I trust you're not going to tell
me I need to spell with an obnoxious hyphen-minus or underscore before
the standard number ("8859")...?

I would then wonder why I am not equally compelled to write "ISO-9000".
Or, to name a standard that comes up in documents to which I contribute,
"ISO-6429" (better known to some as ECMA-48, and yes, ECMA standards
routinely get the hyphen-minus).

> I'm okay with reverting those if there's consensus.  Would you mind
> CCing the interested parties (e.g., the people that requested that
> change, and anybody that participated in the discussion)?
> 
> (I've CCed them now, anyway.)

Thanks for looping Helge in.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: names of ISO 8859 encodings

[Helge Kreutzmann]

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

Hello Branden,
hello Bruno,
hell Alejandro,
Am Fri, Dec 13, 2024 at 06:56:54PM -0600 schrieb G. Branden Robinson:
> At 2024-12-14T01:37:16+0100, Alejandro Colomar wrote:
> > On Sat, Dec 14, 2024 at 01:23:09AM +0100, Bruno Haible wrote:
> > > Commit 3ed1de0ddccb42bae4151c7225d3fddeab04ff43 should better
> > > be reverted, IMO. The ISO organization or their *standards* can
> > > be renamed to whatever names; what matters here is what the
> > > *encoding* is commonly referred to.

There is no "renaming" intended. It is just the proper name of the
standard, which is often (probably because of sloppiness) forgotten.
There are two organizations who joined forces to create these
standards: ISO and IEC. Dropping half of them is not very nice and so
far, precision is what is good about the (man) documentation. You
should be able to rely on the documentation. So why should you stop
short when giving credit and citing documents correctly? And yes, the
correct name contains "ISO/IEC"[1].

Of course, how you name them in your day to day communication is up to
you (and should be so), but in the documentation it should be correct.

Disclaimer: I'm editor of ISO/IEC standards, but not in the field of
character encondings.

> > > The *encoding* names are standardized by IANA:
> > > https://www.iana.org/assignments/character-sets/character-sets.xhtml
> > > The first ISO 8859 encoding there has the name
> > >   ISO-8859-1
> > > or
> > >   ISO_8859-1
> > > and the first among these is the preferred MIME name. So, please,
> > > in encoding names:
> > >   * revert the ISO -> ISO/IEC change,
> > >   * change the space after ISO to a dash/hyphen-minus.
> > > 
> > > Likewise (partially) for commit d5e5db91ece5955b21ae1aedc03ba1d56d3cf423.
> 
> Oy vey.  Helge Kreutzmann submitted a similar bug report to groff and I
> was planning to make the ISO -> ISO/IEC change to its man pages.

I'm not going into the business of valuating which standards should be
adhered to. But when referrring to the proper document the correct
name should be given IMHO.

> Also your point seems more strident than clear to me as regards the
> encoding name.  If I want to refer to character encoding _not_ in the
> context of a machine-parsed MIME datum, I trust you're not going to tell
> me I need to spell with an obnoxious hyphen-minus or underscore before
> the standard number ("8859")...?

My personal opinion is that correct typography is important, but on
quick reading I probably would not spot the differences amongs the
various dashes for example. So for me, having all the correct letters
is important and of course, to copy and paste text (e.g. code) where
necessary, even if that violates typography standards.

And yes, I'm well aware that Branden and Donald Knuth (and successors)
strive for well printed documents, and I'm glad for this.

Greetings

           Helge

[1] I carefully checked this. There are, of course, lots of standards
    purely from ISO (ISO 9001 comes to mind) and from IEC (e.g. IEC
    62443).

-- 
      Dr. Helge Kreutzmann                     debian@helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: names of ISO 8859 encodings

[G. Branden Robinson]

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

Hi Helge,

At 2024-12-14T06:12:15+0000, Helge Kreutzmann wrote:
> Am Fri, Dec 13, 2024 at 06:56:54PM -0600 schrieb G. Branden Robinson:
> > Oy vey.  Helge Kreutzmann submitted a similar bug report to groff
> > and I was planning to make the ISO -> ISO/IEC change to its man
> > pages.
> 
> I'm not going into the business of valuating which standards should be
> adhered to. But when referrring to the proper document the correct
> name should be given IMHO.

Possibly the "use/mention" distinction of linguistics would be helpful
here.[1]  In some technical discussion contexts, we merely _mention_ a
character encoding standard.  For instance, "This program is capable of
transliterating any document using an ISO/IEC 8859 character encoding to
valid UTF-8.".

In other contexts, we _use_ the identifier itself, perhaps as an input
argument to a program.  For example:

   $ iconv -f iso-8859-1 -t utf-8 NEWS

In this shell command, we must spell the character encoding specifiers
exactly as such,[2] and when documenting the foregoing in an example in
a man page, we are well advised to spell the hyphen-minus signs with
leading backslashes.

.RS
.EX
$ \c
.B "iconv \-f iso\-8859\-1 \-t utf\-8 NEWS"
.EE
.RE

Alex, do you think this issue is enough of a trip hazard to warrant
presentation in man-pages(7)?

> My personal opinion is that correct typography is important, but on
> quick reading I probably would not spot the differences amongs the
> various dashes for example. So for me, having all the correct letters
> is important and of course, to copy and paste text (e.g. code) where
> necessary, even if that violates typography standards.

I think we can avoid violating standards of typography; more precisely,
the process of rendering to an output device of limited capability will
violate those standards for us.[3]  For example, a character-cell
terminal device generally can't (1) render arbitrary glyphs sequences
superscripted or subscripted[4]; (2) change the type size;[5] or (3)
change the font family (to use letterforms with or without serifs) for
only part of the rendered text (as opposed to the entire display,
including scrollback buffer) at once.

> And yes, I'm well aware that Branden and Donald Knuth (and successors)
> strive for well printed documents, and I'm glad for this.

That's pretty august company to be paired with.  Lest anyone get any
inflated notions of my role in groff, Joe Ossanna of Bell Labs wrote
troff in the mid-1970s.  After his untimely death, Brian Kernighan
refactored troff circa 1980 into "device-independent troff".  These were
proprietary to AT&T (and commercial products for a while), so the FSF
hired James Clark to write a clean reimplementation of AT&T troff,
called groff, in about 1989.  Werner Lemberg later became groff
maintainer and added many features to it such that it became a viable
alternative to TeX in many more applications (partisan preferences
aside).  Then Bertrand Garrigues did some mostly unsung but badly needed
work on groff's build system, making it more pleasant to work with.  My
role has largely been (1) fixing bugs; (2) writing automated tests to
(try to) ensure that dead bugs stay dead; (3) revising and correcting
documentation; and (4) making modest extensions and reforms to the *roff
language and some of the macro packages, provoking heated arguments
and/or revealing formerly unspecified behavior, around which some people
of course poured fast-drying cement in fits of delirium years ago.

In software as in religion, the commandments held most sacrosanct are
those that no one thought to write down in the first place.

("Of _course_ I can interchange pointers and ints.  No one ever said I
can't!"  Eventually, they did say so.  To much gnashing of teeth.)

Regards,
Branden

And now the footnotes, where we play free-association rambling bingo.

[1]  https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction

[2]  a given system's iconv(1) command may recognize alternative names
     for some encodings

[3]  For example, the bash(1) man page contains this:

.if n Bash is Copyright (C) 1989-2024 by the Free Software Foundation, Inc.
.if t Bash is Copyright \(co 1989-2024 by the Free Software Foundation, Inc.

     In principle, this shouldn't be necessary.  Chet should just write
     the second line without the ".if t" conditional and delete the
     first.  The output device should know how to gracefully map the
     special character "\(co" to a copyright sign, and itself do the job
     of translating it to "(C)" if it has only an ASCII repertoire.
     Presumably, at some point in the past Chet (or the initial Bash
     maintainer, Brian Fox) used an nroff program that was defective,
     and also labored under the no-longer-correct misconception that
     omitting a copyright symbol from one's notice was a fatal defect
     that effectively placed the work in the public domain.  That
     stopped being true as of 1 March 1989.[7]  Further, prior to
     guidance issued by the U.S. Copyright Office in the decades since,
     the use of "(C)" as a substitute for a copyright sign _may not have
     sufficed_ to prevent the copyright notice from being regarded as
     defective.  The Copyright Office, then and now, prefers the
     abbreviation "copr." when © is typographically unavailable.[7]
     Nowadays, its advice is that "c" (note lowercase) is an "acceptable
     variant", that _may_ retain the efficacy of the copyright notice.
     However, it is not the U.S. Copyright Office but the courts that
     ultimately arbitrate such things.  Moreover, given recent
     developments, the Office's guidance to authors need not carry any
     weight to a federal judge.  Between the U.S. Supreme Court's repeal
     of "Chevron Deference"[8] and the availability of a federal
     district court in Western Texas offering itself as a venue to any
     right-wing plaintiff in the country and pursuing a crusade of
     maximalist Federalist [read: monarchist] Society doctrine with a
     penchant for issuing nationwide permanent injunctions,[9][10] the
     status of any federal statute, executive agency guidance, or even
     constitutional provision[11] is uncertain for the next few years at
     least.  But rest assured--we term this sort of radical disruption
     of American jurisprudence a "conservative" judicial philosophy.  👍

[4]  Often, the decimal digits 0-9 are available as superscripts.  This
     selection is too meager for general typography, let alone
     mathematical typesetting where arbitrary, complex expressions may
     occur in exponents, for instance.  Occasionally you need an
     integral up there.

[5]  The DEC VT100 and its successors could do double-width and
     double-size type.[6]  Try this in your preferred terminal emulator.

     $ printf "$(tput bold)\e#3See also\n\e#4See also$(tput sgr0)\n\
          $(tput sitm)xterm$(tput ritm)(1)\n\n\e#6Patch #395    2024-09-11\
          $(tput sitm)xterm$(tput ritm)(1)\e#5\n"

     Anyone think these are worth supporting in grotty(1)?  ;-)

[6]  https://vt100.net/docs/vt510-rm/DECDHL.html
     https://vt100.net/docs/vt510-rm/DECDWL.html

[7]  https://www.copyright.gov/circs/circ03.pdf
[8]  https://www.scotusblog.com/2024/06/supreme-court-strikes-down-chevron-curtailing-power-of-federal-agencies/
[9]  https://www.americanprogress.org/article/the-5th-circuit-court-of-appeals-is-spearheading-a-judicial-power-grab/

[10] I would not personally wager that copyright holders have much to
     fear under the current regime; revenues consequent to copyrights
     are a form of monopoly rent and therefore a worldwide tent pole of
     conservative political economy.  But, if a poweful stakeholder has
     a prospect of a sufficiently large windfall from a radical change
     to copyright protections, and is willing to spend lavishly enough
     on political campaigns and super PACs, who knows what might happen?

     Here's some model statutory language.  "Any work under copyright by
     any entity other than the Walt Disney Company, its subsidiaries, or
     affiliates, enters the public domain as of January 1 of the year
     subsequent to its fixation in tangible form."

     I mean, that's just "common sense", right?[12]  Only Disney has any
     business adapting anything into a feature film, or exercising
     merchandising rights.  Duh.

[11] https://www.cbsnews.com/news/what-is-birthright-citizenship/

[12] another term debased by conservative/centrist political rhetoric

     I offer my own definition, in the spirit of Ambrose Bierce.

     "Commonsense solution": a course of action I want to take for
     reasons I will not share with you.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: names of ISO 8859 encodings

[Alejandro Colomar]

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

Hi Branden,

On Sat, Dec 14, 2024 at 09:47:13AM -0600, G. Branden Robinson wrote:
> At 2024-12-14T06:12:15+0000, Helge Kreutzmann wrote:
> > Am Fri, Dec 13, 2024 at 06:56:54PM -0600 schrieb G. Branden Robinson:
> > > Oy vey.  Helge Kreutzmann submitted a similar bug report to groff
> > > and I was planning to make the ISO -> ISO/IEC change to its man
> > > pages.
> > 
> > I'm not going into the business of valuating which standards should be
> > adhered to. But when referrring to the proper document the correct
> > name should be given IMHO.

I agree.

> 
> Possibly the "use/mention" distinction of linguistics would be helpful
> here.[1]  In some technical discussion contexts, we merely _mention_ a
> character encoding standard.  For instance, "This program is capable of
> transliterating any document using an ISO/IEC 8859 character encoding to
> valid UTF-8.".
> 
> In other contexts, we _use_ the identifier itself, perhaps as an input
> argument to a program.  For example:
> 
>    $ iconv -f iso-8859-1 -t utf-8 NEWS
> 
> In this shell command, we must spell the character encoding specifiers
> exactly as such,[2] and when documenting the foregoing in an example in
> a man page, we are well advised to spell the hyphen-minus signs with
> leading backslashes.
> 
> .RS
> .EX
> $ \c
> .B "iconv \-f iso\-8859\-1 \-t utf\-8 NEWS"
> .EE
> .RE
> 
> Alex, do you think this issue is enough of a trip hazard to warrant
> presentation in man-pages(7)?

What's the issue?  I think it's simple:

When referring to a standard, use the pedantically correct name for it.
When showing a command line, use text that is pedantically correct to
the command interpreter.

Am I missing anything?

Cheers,
Alex

> 
> > My personal opinion is that correct typography is important, but on
> > quick reading I probably would not spot the differences amongs the
> > various dashes for example. So for me, having all the correct letters
> > is important and of course, to copy and paste text (e.g. code) where
> > necessary, even if that violates typography standards.
> 
> I think we can avoid violating standards of typography; more precisely,
> the process of rendering to an output device of limited capability will
> violate those standards for us.[3]  For example, a character-cell
> terminal device generally can't (1) render arbitrary glyphs sequences
> superscripted or subscripted[4]; (2) change the type size;[5] or (3)
> change the font family (to use letterforms with or without serifs) for
> only part of the rendered text (as opposed to the entire display,
> including scrollback buffer) at once.
> 
> > And yes, I'm well aware that Branden and Donald Knuth (and successors)
> > strive for well printed documents, and I'm glad for this.
> 
> That's pretty august company to be paired with.  Lest anyone get any
> inflated notions of my role in groff, Joe Ossanna of Bell Labs wrote
> troff in the mid-1970s.  After his untimely death, Brian Kernighan
> refactored troff circa 1980 into "device-independent troff".  These were
> proprietary to AT&T (and commercial products for a while), so the FSF
> hired James Clark to write a clean reimplementation of AT&T troff,
> called groff, in about 1989.  Werner Lemberg later became groff
> maintainer and added many features to it such that it became a viable
> alternative to TeX in many more applications (partisan preferences
> aside).  Then Bertrand Garrigues did some mostly unsung but badly needed
> work on groff's build system, making it more pleasant to work with.  My
> role has largely been (1) fixing bugs; (2) writing automated tests to
> (try to) ensure that dead bugs stay dead; (3) revising and correcting
> documentation; and (4) making modest extensions and reforms to the *roff
> language and some of the macro packages, provoking heated arguments
> and/or revealing formerly unspecified behavior, around which some people
> of course poured fast-drying cement in fits of delirium years ago.
> 
> In software as in religion, the commandments held most sacrosanct are
> those that no one thought to write down in the first place.
> 
> ("Of _course_ I can interchange pointers and ints.  No one ever said I
> can't!"  Eventually, they did say so.  To much gnashing of teeth.)
> 
> Regards,
> Branden
> 
> And now the footnotes, where we play free-association rambling bingo.
> 
> [1]  https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction
> 
> [2]  a given system's iconv(1) command may recognize alternative names
>      for some encodings
> 
> [3]  For example, the bash(1) man page contains this:
> 
> .if n Bash is Copyright (C) 1989-2024 by the Free Software Foundation, Inc.
> .if t Bash is Copyright \(co 1989-2024 by the Free Software Foundation, Inc.
> 
>      In principle, this shouldn't be necessary.  Chet should just write
>      the second line without the ".if t" conditional and delete the
>      first.  The output device should know how to gracefully map the
>      special character "\(co" to a copyright sign, and itself do the job
>      of translating it to "(C)" if it has only an ASCII repertoire.
>      Presumably, at some point in the past Chet (or the initial Bash
>      maintainer, Brian Fox) used an nroff program that was defective,
>      and also labored under the no-longer-correct misconception that
>      omitting a copyright symbol from one's notice was a fatal defect
>      that effectively placed the work in the public domain.  That
>      stopped being true as of 1 March 1989.[7]  Further, prior to
>      guidance issued by the U.S. Copyright Office in the decades since,
>      the use of "(C)" as a substitute for a copyright sign _may not have
>      sufficed_ to prevent the copyright notice from being regarded as
>      defective.  The Copyright Office, then and now, prefers the
>      abbreviation "copr." when © is typographically unavailable.[7]
>      Nowadays, its advice is that "c" (note lowercase) is an "acceptable
>      variant", that _may_ retain the efficacy of the copyright notice.
>      However, it is not the U.S. Copyright Office but the courts that
>      ultimately arbitrate such things.  Moreover, given recent
>      developments, the Office's guidance to authors need not carry any
>      weight to a federal judge.  Between the U.S. Supreme Court's repeal
>      of "Chevron Deference"[8] and the availability of a federal
>      district court in Western Texas offering itself as a venue to any
>      right-wing plaintiff in the country and pursuing a crusade of
>      maximalist Federalist [read: monarchist] Society doctrine with a
>      penchant for issuing nationwide permanent injunctions,[9][10] the
>      status of any federal statute, executive agency guidance, or even
>      constitutional provision[11] is uncertain for the next few years at
>      least.  But rest assured--we term this sort of radical disruption
>      of American jurisprudence a "conservative" judicial philosophy.  👍
> 
> [4]  Often, the decimal digits 0-9 are available as superscripts.  This
>      selection is too meager for general typography, let alone
>      mathematical typesetting where arbitrary, complex expressions may
>      occur in exponents, for instance.  Occasionally you need an
>      integral up there.
> 
> [5]  The DEC VT100 and its successors could do double-width and
>      double-size type.[6]  Try this in your preferred terminal emulator.
> 
>      $ printf "$(tput bold)\e#3See also\n\e#4See also$(tput sgr0)\n\
>           $(tput sitm)xterm$(tput ritm)(1)\n\n\e#6Patch #395    2024-09-11\
>           $(tput sitm)xterm$(tput ritm)(1)\e#5\n"
> 
>      Anyone think these are worth supporting in grotty(1)?  ;-)
> 
> [6]  https://vt100.net/docs/vt510-rm/DECDHL.html
>      https://vt100.net/docs/vt510-rm/DECDWL.html
> 
> [7]  https://www.copyright.gov/circs/circ03.pdf
> [8]  https://www.scotusblog.com/2024/06/supreme-court-strikes-down-chevron-curtailing-power-of-federal-agencies/
> [9]  https://www.americanprogress.org/article/the-5th-circuit-court-of-appeals-is-spearheading-a-judicial-power-grab/
> 
> [10] I would not personally wager that copyright holders have much to
>      fear under the current regime; revenues consequent to copyrights
>      are a form of monopoly rent and therefore a worldwide tent pole of
>      conservative political economy.  But, if a poweful stakeholder has
>      a prospect of a sufficiently large windfall from a radical change
>      to copyright protections, and is willing to spend lavishly enough
>      on political campaigns and super PACs, who knows what might happen?
> 
>      Here's some model statutory language.  "Any work under copyright by
>      any entity other than the Walt Disney Company, its subsidiaries, or
>      affiliates, enters the public domain as of January 1 of the year
>      subsequent to its fixation in tangible form."
> 
>      I mean, that's just "common sense", right?[12]  Only Disney has any
>      business adapting anything into a feature film, or exercising
>      merchandising rights.  Duh.
> 
> [11] https://www.cbsnews.com/news/what-is-birthright-citizenship/
> 
> [12] another term debased by conservative/centrist political rhetoric
> 
>      I offer my own definition, in the spirit of Ambrose Bierce.
> 
>      "Commonsense solution": a course of action I want to take for
>      reasons I will not share with you.



-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

on the need for better quotation in man(7) (was: names of ISO 8859 encodings)

[G. Branden Robinson]

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

[looping in groff@gnu]

Hi Alex,

At 2024-12-14T18:27:14+0100, Alejandro Colomar wrote:
> [I wrote:]
> > Alex, do you think this issue is enough of a trip hazard to warrant
> > presentation in man-pages(7)?
> 
> What's the issue?  I think it's simple:
> 
> When referring to a standard, use the pedantically correct name for
> it.  When showing a command line, use text that is pedantically
> correct to the command interpreter.

I agree.

> Am I missing anything?

Only that people may sometimes not be clear on which is which.  That is
why it is important to typographically distinguish the cases.
Traditionally this has been difficult in man pages, I think because (1)
the man(7) package has no macros for quotation; (2) idioms for displayed
examples and other I/O were not in Seventh Edition and slow to evolve.

I think some of the blame for (2) can be laid at the feet of the "it's
reference, not a tutorial" camp.  Even references sometimes need
exhibits.

With Chet Ramey's kind indulgence, I've been trialling a simple
quotation macro `Q` in the bash man pages (bash(1), readline(3),
history(3)) this year.[1]  I have an alternative design for quotation
macros in mind as a future groff man(7) development.[2]

Regards,
Branden

[1] https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00027.html

    Chet soon added a `QN` variant to prevent hyphenation, because it's
    a little tricky to achieve that in a quotation context otherwise.

[2] https://lists.gnu.org/archive/html/groff/2023-09/msg00052.html
    https://lists.gnu.org/archive/html/groff/2023-09/msg00058.html

    This is likely due for a cleaned up re-proposal under the new names
    `QS`/`QE` as suggested by Doug McIlroy.  Also, an optional argument
    to disable hyphenation, brought to my attention by Chet this year,
    might be worth having, though mandoc(1) has the problem of
    formatting all arguments to unrecognized macros as text, which is
    not a very *roffy thing to do.  It will do the same with `.YS 0`,
    until and unless mandoc(1) comes to support this extension scheduled
    for groff 1.24.

    Having gained some practical experience with several other man(7)
    corpora, I probably would not float `Q` as a groff man(7) extension;
    I think `QS` and `QE` would suffice.  I am mindful of the benefit of
    keeping the man(7) language as small as possible (but no smaller).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]