Re: Proposed: QS/QE macros for quotation in man(7)

[Dave Kemper]

On Mon, Dec 16, 2024 at 8:28 AM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> I don't feel I have sufficiently broad knowledge of what man-parsing
> tools are out there besides *roffs and mandoc(1).

Fair enough, and perhaps a decent reason on its own to be conservative
with language additions.

> Plan 9 troff is out there, retains the old AT&T/DWB troff limitation of
> two-character names, and in fact implemented the newest groff man(7)
> macro, `MR`, before we did.[2]  And they are limited to two characters.
> That said, I have suspicions that Plan 9 from User Space users don't use
> its troff to render non-Plan-9 man pages.

Having used numerous flavors of Unix over the years, I find it hard to
conceive of an OS package that's so complete that no users ever
download supplementary software.  And once you introduce off-brand
software packages, you're soon introducing off-brand man pages.  So
Plan 9 troff might predominantly, but not exclusively, render Plan 9
man pages. This, to me, also argues for keeping new -man macro names
to two characters.  (And also makes me wonder what sort of bunker the
Plan 9 troff developers are living in that they haven't heard of the
latest 1990s innovations in software design.)

> I find it difficult to locate much
> value in a macro language that's only _partly_ human-readable.  On top
> of the existing crypticness, we'd be adding inconsistency.

On Mon, Dec 16, 2024 at 4:19 AM Alejandro Colomar <alx@kernel.org> wrote:
> I think for consistency sticking to the short format is a good thing,

Both of you made this point, which I find much less convincing than
the above points.  Don't get me wrong, I'm a fan of consistency--but
when it aids comprehension, not simply for consistency's sake.  Using
a consistent name for a widget, or using conventional English
spellings and punctuation, create fewer barriers to understanding.
Maintaining this long-obsolete macro-naming practice creates more
barriers to understanding (albeit only the latest barriers in a
language already replete with them).

As one of you wrote in the unrelated "Novel use of .char" thread: "We
still build monuments to Ken Thompson when deciding how to name
things.  Every concept affords a one-letter abbreviation, two at most,
and any ambiguity that arises is purely a figment of the reader's
sadly limited intellect."  (My only quibble with this is that I
wouldn't lay it entirely at Ken Thompson's feet.  If giving every
variable a MeaningfulCamelCaseName means you run up against storage
limitations significantly sooner, you learn to be terse.)



One final point unrelated to the macro names:

> B2. It would be trivial to support the British, who use the wrong
>     quotation marks^W^W^W^W^Wdrive on the wrong side of the
>     road^W^W^W^W^W^W^W^Whave a different quotation mark convention.

One argument against this is that the difference between American and
British quoting conventions goes beyond which quotation marks are
used; it also affects on which side of a closing quotation mark a
period or comma goes.  And there's no way for groff to figure that
out, which means that, if the macros implement this propoasal, they'd
be modifying only one aspect of quoting style--which might make the
other one seem even more out of place (at least to those sticklers who
notice such things).