Re: [PATCH] minor fixes to Texinfo manual (and AT&T troff behavior)
"G. Branden Robinson" <[email protected]> Sun, 2 Aug 2026 18:04:57 -0500
| Newsgroups | gmane.comp.printing.groff.general |
|---|---|
| Message-ID | <20260802230457.7pzryslmp6hjl3zc@illithid> |
--nfcoch6e3rwk52sm
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] minor fixes to Texinfo manual (and AT&T troff behavior)
MIME-Version: 1.0
Hi Dave,
At 2026-08-02T17:48:46-0500, Dave Kemper wrote:
> I normally put documentation patches in a savannah ticket, since
> they're usually not of interest to the general groff community, but
> the changes proposed here are minor, and having a ticket triggers an
> update to ChangeLog, which this change doesn't otherwise warrant. So
> I'm choosing to submit this patch to this list as the lowest-overhead
> solution.
>=20
> Changes included in the attached patch are:
>=20
> doc/groff.texi.in: Fix style nits.
>=20
> * Add commas before "and"s introducing independent clauses where
> the "and" might otherwise be temporarily misread as part of a
> compound predicate.
> * Use parentheses rather than dashes to set off a parenthetical
> after an item in a series: the dashes require omitting a comma,
> making it harder to parse the construction as a series.
> * Parallelize a series.
> * Fix a typo.
These all look fine to me. I appreciate the cleanups. I'm inlining
your patch for ease of review. (But an attachment is easier to "git
apply", so each approach has its uses.)
Would you like to commit this yourself? You've already written the
commit log and everything (above).
diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index 16de20267..50257538b 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -8581,7 +8581,7 @@ Generally,
a space
@emph{within}
a request argument is not relevant,
-not meaningful,
+is not meaningful,
or is supported by bespoke provisions,
as with the
@code{tl}
@@ -12467,7 +12467,7 @@ request are invocations by paragraphing macros;
(1) to set up a first-line indentation of positive sign;
and
(2) to set up a ``normal'' temporary indentation of negative sign
-offsetting a posiitive indentation
+offsetting a positive indentation
that applies to the whole parargraph,
known as a ``hanging indent''.
@endDefreq
@@ -14345,7 +14345,7 @@ indexed,
have certain associated properties.
The argument
@var{n}
-is the sum of the desired flags
+is the sum of the desired flags,
and the remaining arguments are the characters
to be assigned those properties.
Some property combinations are nonsensical,
@@ -22895,7 +22895,7 @@ or for instrumentation while troubleshooting. The =
@code{ex} and
exit codes respectively, to halt further processing when continuing
would be fruitless.
Examine the state of the formatter with requests that write lists of
-defined names---macros, strings, and diversions---colors,
+defined names (macros, strings, and diversions), colors,
composite character mappings,
environments,
occupied font mounting positions,
@@ -24827,7 +24827,7 @@ if the buffer is of fixed size,
the formatter performs the flush when the buffer runs out of room.
=20
In the somewhat pathological case where a diversion exists
-containing a partially collected line
+containing a partially collected line,
and a partially collected line at the top-level diversion
has never existed,
@acronym{AT&T}
I have started to suspect that a deeper reason for the phenomenon
observed in the last hunk. Here's the full text.
>> In the somewhat pathological case where a diversion exists
>> containing a partially collected line and a partially collected line
>> at the top-level diversion has never existed, AT&T 'troff' outputs a
>> partially collected but otherwise empty line (as if '\c' were in the
>> top-level diversion) at the end of input; GNU 'troff' does not.
My sniffer suggests to me now that as soon as AT&T troff performs _any_
read of input--even an EOF or a failed read from a closed file
descriptor--it pumps out the ditroff header. Then, exhausting input
immediately, it pumps out the trailer.
$ solaris10 troff <&-
x T post
x res 720 1 1
x init
x trailer
V0
x stop
$ solaris10 troff < /dev/null
x T post
x res 720 1 1
x init
x trailer
V0
x stop
Plan 9 from User Space, DWB 3.3, and Heirloom Doctools troffs all behave
the same way, with varying default device names and resolutions.
So that final esoteric paragraph might be a specialized case of a more
general and recent claim I make earlier in the same section.
>> GNU 'troff' does not emit output if it has nothing to format. For
>> example, it treats an input document consisting solely of 'nr' and
>> 'tm' requests as empty, and produces nothing on its standard output
>> stream. AT&T 'troff' does, creating a blank page.
Regards,
Branden
--nfcoch6e3rwk52sm
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpvzRIACgkQ0Z6cfXEm
bc7bFA//VEbFZjpyPh4SyUGwaLFZEj2cz3Oou+/XXY5Qq1usJgJei1qPmV5TEXJq
3gAwiPBlU3dGzPDQN6gq7+l7ohKDFVJWu4UmRSl1v1Tl3bjBFA4zRH3SFExw05MH
pDP+FQKT5PcXc9Aw8jW3la/y2VSjxpbu0xdzJpPkAicvNqWmmncf9turwQHb8tTC
3HwQP0ZFU0mm8v4zSiZJg29W9QsX1J/iKQsGekugSZfHf5mvR1NP7UQkXzDvBLVK
Ek2C2XE4uYKAmAUZ/3Kwejydzbb9KUDmR31hD5XGkvQlp8AxuYg+0i24NAvgXQ+z
Mx4z4up7Qm3N5dki26dkAlbqI7F3puVXecV3/59VhhIY5zGjzciC4mNQRridxXtH
LkwzThC72aRE7JCU2y90/WjYF/vbg1Gs8YOOvRMUQkuOZdp5pcktlHl1JdACN0uB
opGSHpNC2egMb/pnwDyGt9MJaS6ZkPGxcTZfaazk56vePJhhyjB19vBwNrW3oi9A
o9LGAmTT7SHUd+p9VDMVtz9MVQyd0CHOBeahrioqJPc91746Zv1/qKmi+f7kxk4c
497NiKJ7ytDVA9w5LEIzf3Yx1iP/jas0NJHI7haf1vP3xQbDkATOoGaKMOPMjbnh
JsB2KZ7UIQziexRSfnNx7avqk76gUOA1PS5YcVoaHh9BR9hfaU0=
=inMg
-----END PGP SIGNATURE-----
--nfcoch6e3rwk52sm--