Hi Branden,
I dispute that it wasn't harming anybody. The fact that all the same
> characters were valid as delimiters as in identifiers, combined with AT&T
> troff's lack of an "interpolation depth" concept, meant that it was
> _impossible_ to robustly do things like formatted output comparisons
> involving string or register identifiers.
I'm sorry, I still don't quite follow. You can use alphanumerics as
delimiters too, and other commonly-used, non-C0 delimiter characters (like
apostrophes) are legal in identifiers just like C0 control characters are:
.ds ' Apostrophe
.if B\*'BApostropheB \{\
. nop U+0027 is an \*' character.
.\}
And in fact the premier use of the five control characters at issue:
> […]
> ...was historically seen only in delimiters.
So this is how we determine which parts of CSTR-54 are to be honoured and
upheld, and which parts are open to interpretation? By gauging historical
usage? Do independent macro authors and general Roff hacking enthusiasts
not count?
I'm sure--but who has ever actually done this? Can you point me to examples?
I have. I'm putting my cards on the table here, but I have a macro package
named Mono that's designed to work with as many Troff implementations (both
current and historic), gracefully degrading in the absence of more modern
approaches.[1] To this end, it sticks to a 2-character namespace, and to
limit the risk of clobbering an existing 2-character string or register
definition, throwaway registers/strings defined within the body of a macro
to hold temporary values use the prickliest, least-likely-to-be-used names
possible (which are removed before the macro's end).
Here's an example of where this is done: Mono's .``
<https://github.com/Alhadis/Mono/blob/25765171fbf676b623a4bcbf3d9f93384ef83040/ono.tmac#L250-L302>
macro, used to format a code-block (specifically, my current terminal
session at the moment…):
.`` shell-session 4m
$ groff -Tutf8 -M ~/Labs/Mono -mono test.roff 2>&1 | trimend | uniq
troff:/Users/Alhadis/Labs/Mono/ono.tmac:863: error: character code 5 is not
allowed in an identifier
troff:test.roff:3: error: character code 2 is not allowed in an identifier
(printed ×3)
troff:test.roff:12: error: character code 2 is not allowed in an identifier
(printed ×3)
.``
When the opening .`` is called, a temporary macro named .`^B is defined
that restores the settings (indent, font, hyphenation, fill-mode, etc) that
were changed by the macro, whose original values were "baked" into .`^B by
interpolating their values with one less “\” than would normally be used.
But enough of the rambling advertisement. Do I expect you (or anybody else,
really) to give a two shits about my half-finished macro-package? No. Do I
expect you, as maintainer, to sanction breaking changes to Groff's syntax *if
and only if* there's a *convincing, compelling, and practical reason for
doing so?* Yes.
I would guess, though I don't know, that's exactly why DWB 3.3 took the
> decision to ban C0 controls from use in identifiers.
If *I* had to guess, it had more to do with DWB's implementation of
terminal driving tables
<https://github.com/n-t-roff/DWB3.3/blob/2dcc55026310cccef38dcd549b140bf15dfd3f0f/text/nterm/README>
which
need to reserve certain control characters that map to functions and
physical motions in hardware teletypes. Here's the driving table for a Model
37
<https://github.com/n-t-roff/DWB3.3/blob/094c0be1f5ec0b63cd3383a0c670bc53d4af40e3/text/nterm/tab.37>
.
But please, enough with the DWB whataboutisms already. This isn't about
portability to historical Troff versions, *it's about portability between
Groff versions.* And you know that as well as I do.
It also happens to be the case that when you view [documents] in, say, the
> Firefox web browser when visiting the TUHS "Unix Tree", these control
> characters simply aren't visible.
1. *TUHS can always use an embedded webfont to display “invisible”
control characters.* Find an example CSS snippet with a data URI-encoded
WOFF2 font I hacked together just now as a POC.
2. *The issue of visibility affects delimiters as well.* So it's not as
though banning C0 characters in identifiers is adding any rendering issues
that TUHS doesn't already suffer from.
3. *You can configure Firefox to show such control characters in text. *
Open about:config and enable the following flags:
- layout.css.control-characters.visible
<https://searchfox.org/firefox-main/rev/7b08fa00f500ed877b16983a6a77d2c852aad1d0/modules/libpref/init/StaticPrefList.yaml#10350>
- layout.css.moz-control-character-visibility.enabled
<https://searchfox.org/firefox-main/rev/7b08fa00f500ed877b16983a6a77d2c852aad1d0/modules/libpref/init/StaticPrefList.yaml#10210>
Note that Firefox already displays control characters in pages displayed
as plain-text (e.g., *file://localhost/tmp/foo.txt*, or ono.tmac
<https://raw.github.com/Alhadis/Mono/HEAD/ono.tmac>).[2]
I don't know how else to conclude this e-mail, so I'll end with the only
topically-appropriate way I know how.
— Alhadis
*Manually inserted footnotes, BiblioBrandenᵀᴹ style:*
[1]: E.g., the C/A/T phototypesetter didn't support true line-drawing, so
Mono's .UL macro employs \l'…' to print repeated underscores, and a proper \D'l
…' for more modern Troffs. For text-based output (.if n …), .cu is used to
underline spaces (though I still need to fix the issue of line-wrapping…)
[2]: See plaintext.css
<https://searchfox.org/firefox-main/rev/7b08fa00f500ed877b16983a6a77d2c852aad1d0/layout/style/res/plaintext.css#8)>
.
On Fri, 6 Mar 2026 at 18:15, G. Branden Robinson <
[email protected]> wrote:
> [self-follow-up to correct an error]
>
> Please ignore the following paragraph.
>
> At 2026-03-06T00:57:57-0600, G. Branden Robinson wrote:
> > First, not trusting file(1), I built a list of "sophisticated"
> > *roff documents by searching for any document that had an AT&T
> > style control request in it. This would, admittedly, not have
> > caught documents that changed the control character before issuing
> > `if` or `ie` requests, or which wrapped or replaced them.
> > (Replacing them would be a pretty neat trick, though Doug
> > McIlroy's Turing-complete simple macro expander would seem to
> > establish that it is, in fact, possible.[8])
>
> The quoted email took a while to compose, and in the course of doing so
> I changed my approach to gathering relevant information. The foregoing
> is a relic thereof.
>
> > [8] https://www.cs.dartmouth.edu/doug/barem4.txt
>
> However, I'm glad to bring attention to this nifty document. :)
>
> Regards,
> Branden
>
/*! @license CSS code and embedded font both released to the Public Domain. */
@font-face{
font-family: C0;
unicode-range: U+02-03, U+05-07;
src: url("data:font/woff2;base64,d09GMgABAAAAAAPcAAsAAAAACMQAAAOMAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAoGYAB0CoUUhToLgRIAATYCJAOCHgQgBYMbB4FGG5AHUVRQOgE+DuOGL5ZoorSYNmclAmfeaHGPh56j9mdm7wvX7CgujEKINc2yfV48Pvhe9dIO00VnxXS0AMuT5K+bOlUzSXI3MaChiEdoN3NacVFLTahjY9FC0T8vaAVSsoL16rqFteb2e2/MRCKxPe0vCCI6SwCgsieZycyWk7Mh4HW0xgcyIxkYGsLw//3ba4PqKMcZXKzzXeSfLgICiL88Cq6ABAUOeAQcmLQEGyIeFCsmVYHGBncjmTHJ0sladUO/AqM+1UcQogBwAMCNQadRyRTlgDvgC5zANxB7AAvATHGzmiaA+VioyeIjWCPG1OpjDVrb7dYhFqXajEJ4B40GTIQAGgmFZAuYi7Eo2Y6SCCayg+s6wIQujWj9urTJPzr5Phn14IEwpR7u6wU38t5mFYW7XNCwjS8WOJ/kqFHC4kI9NkZzvQH+3zPyrnZPGlBqFhrajTth/euUmrrxQIHuO+3zQcPXsI8lH39sWt9rPauR1jZt7LW2+c5QaQ9qStaZL5Iyzrl+5frR5FGktobSZpRbclO143qnIp9fJ8kuJcC4LpWGnqob7XHrDNyR646m884MPNNgm2P3oa4jp+9f36182eDa9eoZ6c0Mpd7uwKn1xjcuqLKvdZVDUkbXbCyrUXqU1WStW/i6F2NlTfloVs0sR+Wam9rd2Hqy+riZhzZvnH1kTC3D3cLIr7UvPHxfHa2gJbJ27+vTpG5ambFQp1VaNWk+pMXga/uudafd5F8JOcf0bpE9auv5Sl1DrtWjebNVDzHZpD8ELp9/3bOFf/G/jec/AvDu6Y2vAPDuWc8DaoidXxfqCsY4QEA9Ox/qF1zqAgLPvlv81SwbAmDVD7E2wtegVxchIuCuEgoInBgW8AmAhfkIINhAJ5OVjSyR/MkBUSI55KuweURUAY8M7CAFb0By/HQgebn6kSbMFtIswpWaBfNOTU95vdTt++U5K+PfPeRbs1fkdVOqbsOZ9jyqpC1NmIAqXYrEbaW3dvqqPe6gn67WcYZU6fO1i9RTRQPVFeUdSWnLY/iYUR8GqaWPTnrojrnSZqvHnEm098n02+6guHl4xYmXIFGSZClSpUmXIVOWbDly5clXoFCRYiU0OkMFFVVSWRVVVVNdDTXVUlsdddVTXwMNNdJYE001EyhIsBChwoSLECmKgz8xOMITEzETC6/oVXlZrcLr1Wv1qboN+Tp1GwIAAA") format("woff2");
}
pre, code{
font-family: C0, sans-serif;
}
