gbranden pushed a commit to branch master
in repository groff.
commit 52eef9add605da45b998ff153a7a654943b90ef2
Author: G. Branden Robinson <[email protected]>
AuthorDate: Fri Dec 19 10:34:23 2025 -0600
[doc,man]: Fix my own BS annotation.
The problem isn't as bad as I feared; I confused _token_ enumerations
("src/roff/troff/token.h") with symbolic aliases for input character
codes ("src/roff/troff/input.h"). We have as much room as we could
practically want for the former.
---
doc/groff.texi.in | 10 +++-------
man/groff.7.man | 10 +++-------
2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/doc/groff.texi.in b/doc/groff.texi.in
index a031f100e..2266987d3 100644
--- a/doc/groff.texi.in
+++ b/doc/groff.texi.in
@@ -7971,13 +7971,9 @@ and thus are allowed as delimiters:
@c and eqn) also allows the delimited `\C`, which is a wart that makes
@c the foregoing "thus" a lie. But expecting the reader to have a
@c command of GNU troff's token types, which _should_ be a mere
-@c implementation detail, is a tall order. When we make GNU troff
-@c handle UTF-8/Unicode internally we'll have a practically unlimited
-@c space for token types (because the internal character type will go
-@c from 8 to 32 bits wide), and can distinguish some that have been
-@c collapsed to date. That would in turn allow us to make
-@c "unformatting" and "asciification" more representative of the
-@c original input.
+@c implementation detail, is a tall order. We can fix this by
+@c introducing separate token types for _delimited_ special characters
+@c and _delimited_ horizontal motions.
@code{\@key{SPC}},
@code{\%},
@code{\@{},
diff --git a/man/groff.7.man b/man/groff.7.man
index 6e2a92656..39f3ca3fd 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -1872,13 +1872,9 @@ and thus are allowed as delimiters:
.\" and eqn) also allows the delimited `\C`, which is a wart that makes
.\" the foregoing "thus" a lie. But expecting the reader to have a
.\" command of GNU troff's token types, which _should_ be a mere
-.\" implementation detail, is a tall order. When we make GNU troff
-.\" handle UTF-8/Unicode internally we'll have a practically unlimited
-.\" space for token types (because the internal character type will go
-.\" from 8 to 32 bits wide), and can distinguish some that have been
-.\" collapsed to date. That would in turn allow us to make
-.\" "unformatting" and "asciification" more representative of the
-.\" original input.
+.\" implementation detail, is a tall order. We can fix this by
+.\" introducing separate token types for _delimited_ special characters
+.\" and _delimited_ horizontal motions.
.BI \[rs] space\c
,
.BR \[rs]% ,
_______________________________________________
groff-commit mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/groff-commit
