`make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide

`make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide

[Hugo Buddelmeijer]

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

Hi Alejandro,

Running `make -R check` fails because the text in futex_waitv.2 and 
console_codes.4 is too wide.

I noticed this when trying to enable the test phase when updating the 
man-pages package in Guix; see https://codeberg.org/guix/guix/pulls/11893

That Guix pull request contains a patch to fix the man-pages so `make 
check` passes; said patch is attached.

Maybe you could device a better patch though, in particular for 
console_codes.  The affected table is much narrower than similar tables, 
so some lines that have to be truncated, would easily fit in one of the 
other tables.  But I couldn't easily figure out what determines the 
column widths, so I didn't fix that.

Also, the Changelog for 6.04 contains some instructions to touch certain 
files to ensure the test suite passes.  I did not attempt to use that 
workaround.

Thanks for maintaining these man pages, they contain such a wealth of 
information.  No need to credit me in case you fix these minor things.

Hugo

[-- Attachment #2: man-pages-fix-make-check.patch --]
[-- Type: text/x-patch, Size: 2737 bytes --]

From 1345875d14b950e6e64b8fd9a8f335efe7ce5ae0 Mon Sep 17 00:00:00 2001
From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
Date: Sat, 17 Oct 2026 10:47:03 +0200
Subject: [PATCH] man/man2/futex_waitv.2: Fix `make check`.
 man/man4/console_codes.4: Fix `make check`.

---
 man/man2/futex_waitv.2   |  3 ++-
 man/man4/console_codes.4 | 20 +++++++++++++++-----
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/man/man2/futex_waitv.2 b/man/man2/futex_waitv.2
index 4158f297d..acafd2829 100644
--- a/man/man2/futex_waitv.2
+++ b/man/man2/futex_waitv.2
@@ -385,7 +385,8 @@ main(void)
 		clock_gettime(CLOCK_MONOTONIC, &timeout);
 		timeout.tv_sec += 1;
 \&
-		woke = my_futex_waitv(waiters, countof(futexes), 0, &timeout, CLOCK_MONOTONIC);
+		woke = my_futex_waitv(waiters, countof(futexes), 0,
+		                      &timeout, CLOCK_MONOTONIC);
 		if (woke == \-1 && (errno != EAGAIN && errno != EWOULDBLOCK))
 			err(EXIT_FAILURE, "my_futex_waitv");
 \&
diff --git a/man/man4/console_codes.4 b/man/man4/console_codes.4
index faf12a66c..8ce182fad 100644
--- a/man/man4/console_codes.4
+++ b/man/man4/console_codes.4
@@ -755,13 +755,23 @@ ESC ] 1 ; \f[I]txt\f[] ST	Set icon name to \f[I]txt\f[].
 ESC ] 2 ; \f[I]txt\f[] ST	Set window title to \f[I]txt\f[].
 ESC ] 4 ; \f[I]num\f[] ; \f[I]txt\f[] ST	Set color \f[I]num\f[] (0-255) to \f[I]txt\f[].
 ESC ] 5 ; 0 ; \f[I]txt\f[] ST	Set the color for bold substitution to \f[I]txt\f[].
-ESC ] 5 ; 1 ; \f[I]txt\f[] ST	Set the color for underline substitution to \f[I]txt\f[].
-ESC ] 5 ; 2 ; \f[I]txt\f[] ST	Set the color for blinking substitution to \f[I]txt\f[].
+ESC ] 5 ; 1 ; \f[I]txt\f[] ST	T{
+Set the color for underline substitution to \f[I]txt\f[].
+T}
+ESC ] 5 ; 2 ; \f[I]txt\f[] ST	T{
+Set the color for blinking substitution to \f[I]txt\f[].
+T}
 ESC ] 5 ; 3 ; \f[I]txt\f[] ST	Set the color for reverse substitution to \f[I]txt\f[].
 ESC ] 5 ; 4 ; \f[I]txt\f[] ST	Set the color for italic substitution to \f[I]txt\f[].
-ESC ] 6 ; 0 ; \f[I]val\f[] ST	Toggle bold rendition: 0=bold, 1=substitute by color.
-ESC ] 6 ; 1 ; \f[I]val\f[] ST	Toggle underscore rendition: 0=underscore, 1=color.
-ESC ] 6 ; 2 ; \f[I]val\f[] ST	Toggle blinking rendition: 0=blinking, 1=color.
+ESC ] 6 ; 0 ; \f[I]val\f[] ST	T{
+Toggle bold rendition: 0=bold, 1=substitute by color.
+T}
+ESC ] 6 ; 1 ; \f[I]val\f[] ST	T{
+Toggle underscore rendition: 0=underscore, 1=color.
+T}
+ESC ] 6 ; 2 ; \f[I]val\f[] ST	T{
+Toggle blinking rendition: 0=blinking, 1=color.
+T}
 ESC ] 6 ; 3 ; \f[I]val\f[] ST	Toggle reverse rendition: 0=reverse, 1=color.
 ESC ] 6 ; 4 ; \f[I]val\f[] ST	Toggle italic rendition: 0=italic, 1=color.
 ESC ] 10 ; \f[I]txt\f[] ST	Set the foreground text color to \f[I]txt\f[].
-- 
2.54.0

Re: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide

[Alejandro Colomar]

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

Hi Hugo,

> Date: 2026-10-17 21:19:22+0200
> From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
>
> Hi Alejandro,
> 
> Running `make -R check` fails because the text in futex_waitv.2 and
> console_codes.4 is too wide.
> 
> I noticed this when trying to enable the test phase when updating the
> man-pages package in Guix; see https://codeberg.org/guix/guix/pulls/11893

Thanks a lot for the report.  I'm very interested in having make check
pass cleanly.

> That Guix pull request contains a patch to fix the man-pages so `make check`
> passes; said patch is attached.

Thanks!

> 
> Maybe you could device a better patch though, in particular for
> console_codes.  The affected table is much narrower than similar tables, so
> some lines that have to be truncated, would easily fit in one of the other
> tables.  But I couldn't easily figure out what determines the column widths,
> so I didn't fix that.

I think Branden might be better at that; I've added him to CC.

> Also, the Changelog for 6.04 contains some instructions to touch certain
> files to ensure the test suite passes.  I did not attempt to use that
> workaround.

Ok.

> Thanks for maintaining these man pages, they contain such a wealth of
> information.

Thanks!  :-)

> No need to credit me in case you fix these minor things.

I will, anyway.  ;)

> 
> Hugo


Have a lovely day!
Alex

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

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

table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[G. Branden Robinson]

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

Hi Alex & Hugo,

At 2026-10-19T08:20:29+0200, Alejandro Colomar wrote:
> > Date: 2026-10-17 21:19:22+0200
> > From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
> > Running `make -R check` fails because the text in futex_waitv.2 and
> > console_codes.4 is too wide.
[...]

I observe that the failure doesn't tell you why the "check" target is
failing.  It simply says "GREP" and then the output of grep itself.  We
are not informed what grep was looking for.

I also observe that setting `V=1` is useless to get these Makefiles to
tell us what they're actually doing.

While attempting to reproduce Hugo's results, I also noticed the
following messages on stderr.

TBL             .tmp/man/man3/matherr.3.eqn
tbl:".tmp/man/man3/matherr.3:204: warning: ignoring excess table entry at row 5, column 6: "\" retval is 0.0/0.0"
tbl:".tmp/man/man3/matherr.3:205: warning: ignoring excess table entry at row 6, column 6: "\" retval is 0.0/0.0"
tbl:".tmp/man/man3/matherr.3:206: warning: ignoring excess table entry at row 7, column 6: "\" retval is x/0.0"
tbl:".tmp/man/man3/matherr.3:241: warning: ignoring excess table entry at row 42, column 6: "\" different from log()"
tbl:".tmp/man/man3/matherr.3:242: warning: ignoring excess table entry at row 43, column 6: "\" different from log()"
tbl:".tmp/man/man3/matherr.3:249: warning: ignoring excess table entry at row 50, column 6: "\" +0 and -0"
tbl:".tmp/man/man3/matherr.3:257: warning: ignoring excess table entry at row 58, column 6: "\" retval is 0.0/0.0"

(These diagnostic messages are new to the forthcoming groff 1.25.)

Inspecting the file:

$ sed -n 194,205p man/man3/matherr.3
.\" Details below from glibc 2.8's sysdeps/ieee754/k_standard.c
.\" A subset of cases were test by experimental programs.
.TS
lB lB lB cB lB
l l l c l.
Function        Type    Result  Msg?    errno
acos(|x|>1)     DOMAIN  HUGE    y       EDOM
asin(|x|>1)     DOMAIN  HUGE    y       EDOM
atan2(0,0)      DOMAIN  HUGE    y       EDOM
acosh(x<1)      DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
atanh(|x|>1)    DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
atanh(|x|==1)   SING    (x>0.0)?        y       EDOM    \" retval is x/0.0

This seems like a straightforward case of someone forgetting to update
the table format--much easier to neglect before I added the new tbl
diagnostic.  In lieu of a formal patch, here are some replacement lines.

lB lB lB cB lB l
l  l  l  c  l  l.
Function	Type	Result	Msg?	errno	\&

(In the meantime, I'll try and see if the leading double quote before
the file name in tbl(1)'s diagnostic is due to groff 1.24/1.25 version
skew in my environment, or a bug in 1.25 I need to fix before final
release.  It looks like the former.

$ ~/groff-HEAD/bin/groff -tz -man -T utf8 man/man3/matherr.3
tbl:man/man3/matherr.3:204: warning: ignoring excess table entry at row 5, column 6: "\" retval is 0.0/0.0"
tbl:man/man3/matherr.3:205: warning: ignoring excess table entry at row 6, column 6: "\" retval is 0.0/0.0"
tbl:man/man3/matherr.3:206: warning: ignoring excess table entry at row 7, column 6: "\" retval is x/0.0"
tbl:man/man3/matherr.3:241: warning: ignoring excess table entry at row 42, column 6: "\" different from log()"
tbl:man/man3/matherr.3:242: warning: ignoring excess table entry at row 43, column 6: "\" different from log()"
tbl:man/man3/matherr.3:249: warning: ignoring excess table entry at row 50, column 6: "\" +0 and -0"
tbl:man/man3/matherr.3:257: warning: ignoring excess table entry at row 58, column 6: "\" retval is 0.0/0.0"
)

> > Maybe you could device a better patch though, in particular for
> > console_codes.  The affected table is much narrower than similar
> > tables, so some lines that have to be truncated, would easily fit in
> > one of the other tables.  But I couldn't easily figure out what
> > determines the column widths, so I didn't fix that.
> 
> I think Branden might be better at that; I've added him to CC.

Here's the table as formatted using groff 1.25 defaults (same as 1.24),
with the preceding paragraph for context and to make the location of the
right margin clear.

     It accepts ESC ] (OSC) for the setting of certain resources.   In  addition
     to  the ECMA‐48 string terminator (ST), xterm(1) accepts a BEL to terminate
     an OSC string.  These are a few of the OSC control sequences recognized  by
     xterm(1):

     ESC ] 0 ; txt ST           Set icon name and window title to txt.
     ESC ] 1 ; txt ST           Set icon name to txt.
     ESC ] 2 ; txt ST           Set window title to txt.
     ESC ] 4 ; num ; txt ST     Set color num (0‐255) to txt.
     ESC ] 5 ; 0 ; txt ST       Set the color for bold substitution to txt.
     ESC ] 5 ; 1 ; txt ST       Set the color for underline substitution to txt.
     ESC ] 5 ; 2 ; txt ST       Set the color for blinking substitution to txt.
     ESC ] 5 ; 3 ; txt ST       Set the color for reverse substitution to txt.
     ESC ] 5 ; 4 ; txt ST       Set the color for italic substitution to txt.
     ESC ] 6 ; 0 ; val ST       Toggle bold rendition: 0=bold, 1=substitute by color.
     ESC ] 6 ; 1 ; val ST       Toggle underscore rendition: 0=underscore, 1=color.
     ESC ] 6 ; 2 ; val ST       Toggle blinking rendition: 0=blinking, 1=color.
     ESC ] 6 ; 3 ; val ST       Toggle reverse rendition: 0=reverse, 1=color.
     ESC ] 6 ; 4 ; val ST       Toggle italic rendition: 0=italic, 1=color.
     ESC ] 10 ; txt ST          Set the foreground text color to txt.
     ESC ] 11 ; txt ST          Set the background color to txt.
     ESC ] 12 ; txt ST          Set the text cursor color to txt.
     ESC ] 13 ; txt ST          Set the mouse cursor foreground color to txt.
     ESC ] 14 ; txt ST          Set the mouse cursor background color to txt.
     ESC ] 15 ; txt ST          Set the Tektronix foreground color to txt.
     ESC ] 16 ; txt ST          Set the Tektronix background color to txt.
     ESC ] 17 ; txt ST          Set  the  background  text color for highlighted (se‐
                                lected) text to txt.
     ESC ] 18 ; txt ST          Set the Tektronix cursor color to txt.
     ESC ] 19 ; txt ST          Set the foreground text color  for  highlighted  (se‐
                                lected) text to txt.
     ESC ] 46 ; name ST         Change  log file to name (normally disabled by a com‐
                                pile‐time option).
     ESC ] 50 ; fn ST           Set font to fn (the escape code is normally disabled;
                                see "allowFontOps" in xterm(1)).
     ESC ] 104 ; num ST         Reset color for mode 4;num
     ESC ] 105 ; num ST         Reset color for mode 5;num
     ESC ] 106 ; num ; val ST   Exactly equal to 6;num;val.  (no "reset" logic)
     ESC ] 110 ST               Reset color for mode 10.  Codes 111‐119 map to reset‐
                                ting modes 11‐19, respectively.
     ESC ] mode ; ? ST          Query  the  respective  property/color/etc.    (modes
                                4,5,10‐19,50)

We can see that this line is troublesome:

     ESC ] 6 ; 0 ; val ST       Toggle bold rendition: 0=bold, 1=substitute by color.

My hunch is that the rightmost column is not set in a text block when it
should be.  What's a text block, you ask?

tbl(1):
   Text blocks
     An ordinary table entry’s contents can make a column, and therefore
     the table, too wide; the table then exceeds the line length of the
     page, and becomes ugly or is exposed to truncation by the output
     device.  When a table entry requires more conventional typesetting,
     breaking across more than one output line (and thereby increasing
     the height of its row), it can be placed within a text block.

     tbl interprets a table entry of “T{” at the end of an input line
     specially, as a token starting a text block.  Similarly, an entry
     “T}” at the start of an input line ends a text block.  Text block
     tokens can share an input line with other table data (preceding T{
     and following T}).  Input lines between these tokens are formatted
     in a diversion by troff.  Text blocks cannot be nested.  Multiple
     text blocks can occur in a table row.
...

So let's check the page source.

$ sed -n 748,762p man/man4/console_codes.4
.TS
l l.
ESC ] 0 ; \f[I]txt\f[] ST       T{
Set icon name and window title to
.IR txt .
T}
ESC ] 1 ; \f[I]txt\f[] ST       Set icon name to \f[I]txt\f[].
ESC ] 2 ; \f[I]txt\f[] ST       Set window title to \f[I]txt\f[].
ESC ] 4 ; \f[I]num\f[] ; \f[I]txt\f[] ST        Set color \f[I]num\f[] (0-255) to \f[I]txt\f[].
ESC ] 5 ; 0 ; \f[I]txt\f[] ST   Set the color for bold substitution to \f[I]txt\f[].
ESC ] 5 ; 1 ; \f[I]txt\f[] ST   Set the color for underline substitution to \f[I]txt\f[].
ESC ] 5 ; 2 ; \f[I]txt\f[] ST   Set the color for blinking substitution to \f[I]txt\f[].
ESC ] 5 ; 3 ; \f[I]txt\f[] ST   Set the color for reverse substitution to \f[I]txt\f[].
ESC ] 5 ; 4 ; \f[I]txt\f[] ST   Set the color for italic substitution to \f[I]txt\f[].
ESC ] 6 ; 0 ; \f[I]val\f[] ST   Toggle bold rendition: 0=bold, 1=substitute by color.

Yup.

The fix is straightforward: put the table cell in a text block.  But
there is one other entry in this table that is too wide.

$ diff -u man/man4/console_codes.4{.old,}
--- man/man4/console_codes.4.old        2026-10-19 07:40:06.562768271 -0500
+++ man/man4/console_codes.4    2026-10-19 07:44:11.729514217 -0500
@@ -759,8 +759,12 @@
 ESC ] 5 ; 2 ; \f[I]txt\f[] ST  Set the color for blinking substitution to \f[I]txt\f[].
 ESC ] 5 ; 3 ; \f[I]txt\f[] ST  Set the color for reverse substitution to \f[I]txt\f[].
 ESC ] 5 ; 4 ; \f[I]txt\f[] ST  Set the color for italic substitution to \f[I]txt\f[].
-ESC ] 6 ; 0 ; \f[I]val\f[] ST  Toggle bold rendition: 0=bold, 1=substitute by color.
-ESC ] 6 ; 1 ; \f[I]val\f[] ST  Toggle underscore rendition: 0=underscore, 1=color.
+ESC ] 6 ; 0 ; \f[I]val\f[] ST  T{
+Toggle bold rendition: 0=bold, 1=substitute by color.
+T}
+ESC ] 6 ; 1 ; \f[I]val\f[] ST  T{
+Toggle underscore rendition: 0=underscore, 1=color.
+T}
 ESC ] 6 ; 2 ; \f[I]val\f[] ST  Toggle blinking rendition: 0=blinking, 1=color.
 ESC ] 6 ; 3 ; \f[I]val\f[] ST  Toggle reverse rendition: 0=reverse, 1=color.
 ESC ] 6 ; 4 ; \f[I]val\f[] ST  Toggle italic rendition: 0=italic, 1=color.

I still got the warning about the table being too wide, spuriously.
That appears to be due a workaround for old bugs in GNU tbl.[1]

$ git grep NROFF_LINE_LENGTH
share/mk/configure/build-depends/groff-base/nroff.mk:ifndef NROFF_LINE_LENGTH
share/mk/configure/build-depends/groff-base/nroff.mk:NROFF_LINE_LENGTH    ::= $(shell $(EXPR) $(MANWIDTH) - 2)
share/mk/configure/build-depends/groff-base/nroff.mk:   -rLL=$(NROFF_LINE_LENGTH)n \

I was able to get a complete, successful check with the following
command.

$ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle

I needed to override `NROFFFLAGS` because of a new warning category in
the forthcoming groff 1.25.

groff NEWS:
*  The formatter supports a new warning category, "style".  It is used
   to diagnose input that is non-idiomatic or likely to produce an
   unexpected result (or none at all), but is not invalid.

One of the things it warns about is failure to break an input line after
the end of a sentence is detected.  The Linux man-pages may want to
disable that warning category by default until those have been cleaned
up.  Enabling it will, of course, permit machine-driven identification
of sites requiring such cleanup, which has to date been tedious,
requiring manual inspection or application of regexes that can be
thwarted by the *roff language's context-dependent grammar.

Regards,
Branden

[1] https://savannah.gnu.org/bugs/?63749
    https://savannah.gnu.org/bugs/?63640
    https://savannah.gnu.org/bugs/?62471

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

Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-10-19 08:02:35-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> Hi Alex & Hugo,
> 
> At 2026-10-19T08:20:29+0200, Alejandro Colomar wrote:
> > > Date: 2026-10-17 21:19:22+0200
> > > From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
> > > Running `make -R check` fails because the text in futex_waitv.2 and
> > > console_codes.4 is too wide.
> [...]
> 
> I observe that the failure doesn't tell you why the "check" target is
> failing.  It simply says "GREP" and then the output of grep itself.  We
> are not informed what grep was looking for.
> 
> I also observe that setting `V=1` is useless to get these Makefiles to
> tell us what they're actually doing.

Hmmm, this gave me a good idea.  I don't like this V variable, since
it's unclear what it should do in each project, but I've played with
this patch:

	diff --git i/GNUmakefile w/GNUmakefile
	index 9f3ced6f461b..9b480fe5e52c 100644
	--- i/GNUmakefile
	+++ w/GNUmakefile
	@@ -16,6 +16,7 @@ endif
	 MAKEFLAGS += --no-builtin-rules
	 MAKEFLAGS += --no-builtin-variables
	 MAKEFLAGS += --warn-undefined-variables
	+MAKEFLAGS += --silent
	 
	 
	 ifndef srcdir
	@@ -66,5 +67,4 @@ help:
	 
	 
	 .DELETE_ON_ERROR:
	-.SILENT:
	 FORCE:

and it seems to work.  If you use --no-silent on the command line, it
overrides the default.  I'll check better before committing.

> While attempting to reproduce Hugo's results, I also noticed the
> following messages on stderr.
> 
> TBL             .tmp/man/man3/matherr.3.eqn
> tbl:".tmp/man/man3/matherr.3:204: warning: ignoring excess table entry at row 5, column 6: "\" retval is 0.0/0.0"
> tbl:".tmp/man/man3/matherr.3:205: warning: ignoring excess table entry at row 6, column 6: "\" retval is 0.0/0.0"
> tbl:".tmp/man/man3/matherr.3:206: warning: ignoring excess table entry at row 7, column 6: "\" retval is x/0.0"
> tbl:".tmp/man/man3/matherr.3:241: warning: ignoring excess table entry at row 42, column 6: "\" different from log()"
> tbl:".tmp/man/man3/matherr.3:242: warning: ignoring excess table entry at row 43, column 6: "\" different from log()"
> tbl:".tmp/man/man3/matherr.3:249: warning: ignoring excess table entry at row 50, column 6: "\" +0 and -0"
> tbl:".tmp/man/man3/matherr.3:257: warning: ignoring excess table entry at row 58, column 6: "\" retval is 0.0/0.0"
> 
> (These diagnostic messages are new to the forthcoming groff 1.25.)
> 
> Inspecting the file:
> 
> $ sed -n 194,205p man/man3/matherr.3
> .\" Details below from glibc 2.8's sysdeps/ieee754/k_standard.c
> .\" A subset of cases were test by experimental programs.
> .TS
> lB lB lB cB lB
> l l l c l.
> Function        Type    Result  Msg?    errno
> acos(|x|>1)     DOMAIN  HUGE    y       EDOM
> asin(|x|>1)     DOMAIN  HUGE    y       EDOM
> atan2(0,0)      DOMAIN  HUGE    y       EDOM
> acosh(x<1)      DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> atanh(|x|>1)    DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> atanh(|x|==1)   SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
> 
> This seems like a straightforward case of someone forgetting to update
> the table format--much easier to neglect before I added the new tbl
> diagnostic.  In lieu of a formal patch, here are some replacement lines.

I'd love a formal patch, especially with a good commit message.  :)

> lB lB lB cB lB l
> l  l  l  c  l  l.
> Function	Type	Result	Msg?	errno	\&
> 
> (In the meantime, I'll try and see if the leading double quote before
> the file name in tbl(1)'s diagnostic is due to groff 1.24/1.25 version
> skew in my environment, or a bug in 1.25 I need to fix before final
> release.  It looks like the former.
> 
> $ ~/groff-HEAD/bin/groff -tz -man -T utf8 man/man3/matherr.3
> tbl:man/man3/matherr.3:204: warning: ignoring excess table entry at row 5, column 6: "\" retval is 0.0/0.0"
> tbl:man/man3/matherr.3:205: warning: ignoring excess table entry at row 6, column 6: "\" retval is 0.0/0.0"
> tbl:man/man3/matherr.3:206: warning: ignoring excess table entry at row 7, column 6: "\" retval is x/0.0"
> tbl:man/man3/matherr.3:241: warning: ignoring excess table entry at row 42, column 6: "\" different from log()"
> tbl:man/man3/matherr.3:242: warning: ignoring excess table entry at row 43, column 6: "\" different from log()"
> tbl:man/man3/matherr.3:249: warning: ignoring excess table entry at row 50, column 6: "\" +0 and -0"
> tbl:man/man3/matherr.3:257: warning: ignoring excess table entry at row 58, column 6: "\" retval is 0.0/0.0"
> )
> 
> > > Maybe you could device a better patch though, in particular for
> > > console_codes.  The affected table is much narrower than similar
> > > tables, so some lines that have to be truncated, would easily fit in
> > > one of the other tables.  But I couldn't easily figure out what
> > > determines the column widths, so I didn't fix that.
> > 
> > I think Branden might be better at that; I've added him to CC.
> 
> Here's the table as formatted using groff 1.25 defaults (same as 1.24),
> with the preceding paragraph for context and to make the location of the
> right margin clear.
> 
>      It accepts ESC ] (OSC) for the setting of certain resources.   In  addition
>      to  the ECMA‐48 string terminator (ST), xterm(1) accepts a BEL to terminate
>      an OSC string.  These are a few of the OSC control sequences recognized  by
>      xterm(1):
> 
>      ESC ] 0 ; txt ST           Set icon name and window title to txt.
>      ESC ] 1 ; txt ST           Set icon name to txt.
>      ESC ] 2 ; txt ST           Set window title to txt.
>      ESC ] 4 ; num ; txt ST     Set color num (0‐255) to txt.
>      ESC ] 5 ; 0 ; txt ST       Set the color for bold substitution to txt.
>      ESC ] 5 ; 1 ; txt ST       Set the color for underline substitution to txt.
>      ESC ] 5 ; 2 ; txt ST       Set the color for blinking substitution to txt.
>      ESC ] 5 ; 3 ; txt ST       Set the color for reverse substitution to txt.
>      ESC ] 5 ; 4 ; txt ST       Set the color for italic substitution to txt.
>      ESC ] 6 ; 0 ; val ST       Toggle bold rendition: 0=bold, 1=substitute by color.
>      ESC ] 6 ; 1 ; val ST       Toggle underscore rendition: 0=underscore, 1=color.
>      ESC ] 6 ; 2 ; val ST       Toggle blinking rendition: 0=blinking, 1=color.
>      ESC ] 6 ; 3 ; val ST       Toggle reverse rendition: 0=reverse, 1=color.
>      ESC ] 6 ; 4 ; val ST       Toggle italic rendition: 0=italic, 1=color.
>      ESC ] 10 ; txt ST          Set the foreground text color to txt.
>      ESC ] 11 ; txt ST          Set the background color to txt.
>      ESC ] 12 ; txt ST          Set the text cursor color to txt.
>      ESC ] 13 ; txt ST          Set the mouse cursor foreground color to txt.
>      ESC ] 14 ; txt ST          Set the mouse cursor background color to txt.
>      ESC ] 15 ; txt ST          Set the Tektronix foreground color to txt.
>      ESC ] 16 ; txt ST          Set the Tektronix background color to txt.
>      ESC ] 17 ; txt ST          Set  the  background  text color for highlighted (se‐
>                                 lected) text to txt.
>      ESC ] 18 ; txt ST          Set the Tektronix cursor color to txt.
>      ESC ] 19 ; txt ST          Set the foreground text color  for  highlighted  (se‐
>                                 lected) text to txt.
>      ESC ] 46 ; name ST         Change  log file to name (normally disabled by a com‐
>                                 pile‐time option).
>      ESC ] 50 ; fn ST           Set font to fn (the escape code is normally disabled;
>                                 see "allowFontOps" in xterm(1)).
>      ESC ] 104 ; num ST         Reset color for mode 4;num
>      ESC ] 105 ; num ST         Reset color for mode 5;num
>      ESC ] 106 ; num ; val ST   Exactly equal to 6;num;val.  (no "reset" logic)
>      ESC ] 110 ST               Reset color for mode 10.  Codes 111‐119 map to reset‐
>                                 ting modes 11‐19, respectively.
>      ESC ] mode ; ? ST          Query  the  respective  property/color/etc.    (modes
>                                 4,5,10‐19,50)
> 
> We can see that this line is troublesome:
> 
>      ESC ] 6 ; 0 ; val ST       Toggle bold rendition: 0=bold, 1=substitute by color.
> 
> My hunch is that the rightmost column is not set in a text block when it
> should be.  What's a text block, you ask?
> 
> tbl(1):
>    Text blocks
>      An ordinary table entry’s contents can make a column, and therefore
>      the table, too wide; the table then exceeds the line length of the
>      page, and becomes ugly or is exposed to truncation by the output
>      device.  When a table entry requires more conventional typesetting,
>      breaking across more than one output line (and thereby increasing
>      the height of its row), it can be placed within a text block.
> 
>      tbl interprets a table entry of “T{” at the end of an input line
>      specially, as a token starting a text block.  Similarly, an entry
>      “T}” at the start of an input line ends a text block.  Text block
>      tokens can share an input line with other table data (preceding T{
>      and following T}).  Input lines between these tokens are formatted
>      in a diversion by troff.  Text blocks cannot be nested.  Multiple
>      text blocks can occur in a table row.
> ...
> 
> So let's check the page source.
> 
> $ sed -n 748,762p man/man4/console_codes.4
> .TS
> l l.
> ESC ] 0 ; \f[I]txt\f[] ST       T{
> Set icon name and window title to
> .IR txt .
> T}
> ESC ] 1 ; \f[I]txt\f[] ST       Set icon name to \f[I]txt\f[].
> ESC ] 2 ; \f[I]txt\f[] ST       Set window title to \f[I]txt\f[].
> ESC ] 4 ; \f[I]num\f[] ; \f[I]txt\f[] ST        Set color \f[I]num\f[] (0-255) to \f[I]txt\f[].
> ESC ] 5 ; 0 ; \f[I]txt\f[] ST   Set the color for bold substitution to \f[I]txt\f[].
> ESC ] 5 ; 1 ; \f[I]txt\f[] ST   Set the color for underline substitution to \f[I]txt\f[].
> ESC ] 5 ; 2 ; \f[I]txt\f[] ST   Set the color for blinking substitution to \f[I]txt\f[].
> ESC ] 5 ; 3 ; \f[I]txt\f[] ST   Set the color for reverse substitution to \f[I]txt\f[].
> ESC ] 5 ; 4 ; \f[I]txt\f[] ST   Set the color for italic substitution to \f[I]txt\f[].
> ESC ] 6 ; 0 ; \f[I]val\f[] ST   Toggle bold rendition: 0=bold, 1=substitute by color.
> 
> Yup.
> 
> The fix is straightforward: put the table cell in a text block.  But
> there is one other entry in this table that is too wide.
> 
> $ diff -u man/man4/console_codes.4{.old,}

No git-diff(1)?  :D

> --- man/man4/console_codes.4.old        2026-10-19 07:40:06.562768271 -0500
> +++ man/man4/console_codes.4    2026-10-19 07:44:11.729514217 -0500
> @@ -759,8 +759,12 @@
>  ESC ] 5 ; 2 ; \f[I]txt\f[] ST  Set the color for blinking substitution to \f[I]txt\f[].
>  ESC ] 5 ; 3 ; \f[I]txt\f[] ST  Set the color for reverse substitution to \f[I]txt\f[].
>  ESC ] 5 ; 4 ; \f[I]txt\f[] ST  Set the color for italic substitution to \f[I]txt\f[].
> -ESC ] 6 ; 0 ; \f[I]val\f[] ST  Toggle bold rendition: 0=bold, 1=substitute by color.
> -ESC ] 6 ; 1 ; \f[I]val\f[] ST  Toggle underscore rendition: 0=underscore, 1=color.
> +ESC ] 6 ; 0 ; \f[I]val\f[] ST  T{
> +Toggle bold rendition: 0=bold, 1=substitute by color.
> +T}
> +ESC ] 6 ; 1 ; \f[I]val\f[] ST  T{
> +Toggle underscore rendition: 0=underscore, 1=color.
> +T}
>  ESC ] 6 ; 2 ; \f[I]val\f[] ST  Toggle blinking rendition: 0=blinking, 1=color.
>  ESC ] 6 ; 3 ; \f[I]val\f[] ST  Toggle reverse rendition: 0=reverse, 1=color.
>  ESC ] 6 ; 4 ; \f[I]val\f[] ST  Toggle italic rendition: 0=italic, 1=color.
> 
> I still got the warning about the table being too wide, spuriously.
> That appears to be due a workaround for old bugs in GNU tbl.[1]
> 
> $ git grep NROFF_LINE_LENGTH
> share/mk/configure/build-depends/groff-base/nroff.mk:ifndef NROFF_LINE_LENGTH
> share/mk/configure/build-depends/groff-base/nroff.mk:NROFF_LINE_LENGTH    ::= $(shell $(EXPR) $(MANWIDTH) - 2)
> share/mk/configure/build-depends/groff-base/nroff.mk:   -rLL=$(NROFF_LINE_LENGTH)n \
> 
> I was able to get a complete, successful check with the following
> command.
> 
> $ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle

Thanks!  Would you mind sending a formal patch set?  =)

> I needed to override `NROFFFLAGS` because of a new warning category in
> the forthcoming groff 1.25.
> 
> groff NEWS:
> *  The formatter supports a new warning category, "style".  It is used
>    to diagnose input that is non-idiomatic or likely to produce an
>    unexpected result (or none at all), but is not invalid.
> 
> One of the things it warns about is failure to break an input line after
> the end of a sentence is detected.  The Linux man-pages may want to
> disable that warning category by default until those have been cleaned
> up.  Enabling it will, of course, permit machine-driven identification
> of sites requiring such cleanup, which has to date been tedious,
> requiring manual inspection or application of regexes that can be
> thwarted by the *roff language's context-dependent grammar.

We'll see when it arrives.  :)


Have a lovely night!
Alex

> 
> Regards,
> Branden
> 
> [1] https://savannah.gnu.org/bugs/?63749
>     https://savannah.gnu.org/bugs/?63640
>     https://savannah.gnu.org/bugs/?62471



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

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

Re: table layout in console_codes.4

[Hugo Buddelmeijer]

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

On 10/19/26 15:02, G. Branden Robinson wrote:
> Hi Alex & Hugo,
> 
> At 2026-10-19T08:20:29+0200, Alejandro Colomar wrote:
>>> Date: 2026-10-17 21:19:22+0200
>>> From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
>>> Running `make -R check` fails because the text in futex_waitv.2 and
>>> console_codes.4 is too wide.
> [...]
> 
> I observe that the failure doesn't tell you why the "check" target is
> failing.  It simply says "GREP" and then the output of grep itself.  We
> are not informed what grep was looking for.

For me the output of `make -R check` was useful enough (using groff 
1.24.0, should have included that):

.tmp/man/man4/console_codes.4:750: warning: table wider than line length 
minus indentation

It does not exactly say which line is too long, so I removed 
'suspicious' lines until the test passed, then added them back one by 
one, adding a text block whenever TROFF complained.  5 lines were to 
wide for the table.

The result looks rather unsatisfactory, see attached screenshot, which 
shows the affected table and the one above it.  The top one is much 
broader.  (I didn't know how to include the text in the email directly 
without messing up the formatting.)

I investigated a bit deeper, and believe that the table is so narrow 
because it uses column specification "l l."; replacing that with "l lx." 
makes the table wider (probably requiring less text blocks).  This was 
just cargo-culted from other tables though.

Hugo

[-- Attachment #2: man-console-pages.png --]
[-- Type: image/png, Size: 44777 bytes --]

Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[G. Branden Robinson]

[-- Attachment #1.1: Type: text/plain, Size: 12666 bytes --]

Hi Alex & Hugo,

At 2026-10-19T18:55:32+0200, Alejandro Colomar wrote:
> > Date: 2026-10-19 08:02:35-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> > At 2026-10-19T08:20:29+0200, Alejandro Colomar wrote:
> > > > Date: 2026-10-17 21:19:22+0200
> > > > From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
> > > > Running `make -R check` fails because the text in futex_waitv.2
> > > > and console_codes.4 is too wide.
> > [...]
> > 
> > I observe that the failure doesn't tell you why the "check" target
> > is failing.  It simply says "GREP" and then the output of grep
> > itself.  We are not informed what grep was looking for.
> > 
> > I also observe that setting `V=1` is useless to get these Makefiles
> > to tell us what they're actually doing.
> 
> Hmmm, this gave me a good idea.  I don't like this V variable, since
> it's unclear what it should do in each project, but I've played with
> this patch:
> 
> 	diff --git i/GNUmakefile w/GNUmakefile
> 	index 9f3ced6f461b..9b480fe5e52c 100644
> 	--- i/GNUmakefile
> 	+++ w/GNUmakefile
> 	@@ -16,6 +16,7 @@ endif
> 	 MAKEFLAGS += --no-builtin-rules
> 	 MAKEFLAGS += --no-builtin-variables
> 	 MAKEFLAGS += --warn-undefined-variables
> 	+MAKEFLAGS += --silent
> 	 
> 	 
> 	 ifndef srcdir
> 	@@ -66,5 +67,4 @@ help:
> 	 
> 	 
> 	 .DELETE_ON_ERROR:
> 	-.SILENT:
> 	 FORCE:
> 
> and it seems to work.  If you use --no-silent on the command line, it
> overrides the default.  I'll check better before committing.

Cool!

> > While attempting to reproduce Hugo's results, I also noticed the
> > following messages on stderr.
> > 
> > TBL             .tmp/man/man3/matherr.3.eqn
> > tbl:".tmp/man/man3/matherr.3:204: warning: ignoring excess table entry at row 5, column 6: "\" retval is 0.0/0.0"
> > tbl:".tmp/man/man3/matherr.3:205: warning: ignoring excess table entry at row 6, column 6: "\" retval is 0.0/0.0"
> > tbl:".tmp/man/man3/matherr.3:206: warning: ignoring excess table entry at row 7, column 6: "\" retval is x/0.0"
> > tbl:".tmp/man/man3/matherr.3:241: warning: ignoring excess table entry at row 42, column 6: "\" different from log()"
> > tbl:".tmp/man/man3/matherr.3:242: warning: ignoring excess table entry at row 43, column 6: "\" different from log()"
> > tbl:".tmp/man/man3/matherr.3:249: warning: ignoring excess table entry at row 50, column 6: "\" +0 and -0"
> > tbl:".tmp/man/man3/matherr.3:257: warning: ignoring excess table entry at row 58, column 6: "\" retval is 0.0/0.0"
> > 
> > (These diagnostic messages are new to the forthcoming groff 1.25.)
> > 
> > Inspecting the file:
> > 
> > $ sed -n 194,205p man/man3/matherr.3
> > .\" Details below from glibc 2.8's sysdeps/ieee754/k_standard.c
> > .\" A subset of cases were test by experimental programs.
> > .TS
> > lB lB lB cB lB
> > l l l c l.
> > Function        Type    Result  Msg?    errno
> > acos(|x|>1)     DOMAIN  HUGE    y       EDOM
> > asin(|x|>1)     DOMAIN  HUGE    y       EDOM
> > atan2(0,0)      DOMAIN  HUGE    y       EDOM
> > acosh(x<1)      DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > atanh(|x|>1)    DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > atanh(|x|==1)   SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
> > 
> > This seems like a straightforward case of someone forgetting to
> > update the table format--much easier to neglect before I added the
> > new tbl diagnostic.  In lieu of a formal patch, here are some
> > replacement lines.
> 
> I'd love a formal patch, especially with a good commit message.  :)

I'm sure.  But I'm dealing with yet another late-release-cycle fire
drill in groff right now, unfortunately.

> > lB lB lB cB lB l
> > l  l  l  c  l  l.
> > Function	Type	Result	Msg?	errno	\&
[...]
> > > > Maybe you could device a better patch though, in particular for
> > > > console_codes.  The affected table is much narrower than similar
> > > > tables, so some lines that have to be truncated, would easily
> > > > fit in one of the other tables.  But I couldn't easily figure
> > > > out what determines the column widths, so I didn't fix that.
> > > 
> > > I think Branden might be better at that; I've added him to CC.
[...]
> > The fix is straightforward: put the table cell in a text block.  But
> > there is one other entry in this table that is too wide.
> > 
> > $ diff -u man/man4/console_codes.4{.old,}
> 
> No git-diff(1)?  :D

Nope; see above.

And on second thought it occurs to me that you may not want that column
in the table after all, since they are all *roff comments intended (I
think) only for inspection by the document maintainer, not by the
reader.  In that case what you want to do is not add a column, but stop
supplying excess table entries--in other words, discard the tab
character before the `\"` comment escape sequence.

diff --git a/man/man3/matherr.3 b/man/man3/matherr.3
index 2e179e358..8711ee3cd 100644
--- a/man/man3/matherr.3
+++ b/man/man3/matherr.3
@@ -200,9 +200,9 @@ .SS Math functions that employ matherr()
 acos(|x|>1)    DOMAIN  HUGE    y       EDOM
 asin(|x|>1)    DOMAIN  HUGE    y       EDOM
 atan2(0,0)     DOMAIN  HUGE    y       EDOM
-acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
-atanh(|x|>1)   DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
-atanh(|x|==1)  SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
+acosh(x<1)     DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
+atanh(|x|>1)   DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
+atanh(|x|==1)  SING    (x>0.0)?        y       EDOM\" retval is x/0.0
 \      \       HUGE_VAL :
 \      \       \-HUGE_VAL
 cosh(fin) o/f  OVERFLOW        HUGE    n       ERANGE
@@ -237,15 +237,15 @@ .SS Math functions that employ matherr()
 \      \       HUGE_VAL,x)
 log(0) SING    \-HUGE  y       EDOM
 log(x<0)       DOMAIN  \-HUGE  y       EDOM
-log2(0)        SING    \-HUGE  n       EDOM    \" different from log()
-log2(x<0)      DOMAIN  \-HUGE  n       EDOM    \" different from log()
+log2(0)        SING    \-HUGE  n       EDOM\" different from log()
+log2(x<0)      DOMAIN  \-HUGE  n       EDOM\" different from log()
 log10(0)       SING    \-HUGE  y       EDOM
 log10(x<0)     DOMAIN  \-HUGE  y       EDOM
 pow(0.0,0.0)   DOMAIN  0.0     y       EDOM
 pow(x,y) o/f   OVERFLOW        HUGE    n       ERANGE
 pow(x,y) u/f   UNDERFLOW       0.0     n       ERANGE
 pow(NaN,0.0)   DOMAIN  x       n       EDOM
-0**neg DOMAIN  0.0     y       EDOM    \" +0 and -0
+0**neg DOMAIN  0.0     y       EDOM\" +0 and -0
 neg**non-int   DOMAIN  0.0     y       EDOM
 scalb() o/f    OVERFLOW        (x>0.0) ?       n       ERANGE
 \      \       HUGE_VAL :
@@ -253,7 +253,7 @@ .SS Math functions that employ matherr()
 scalb() u/f    UNDERFLOW       copysign(       n       ERANGE
 \      \       \ \ 0.0,x)
 fmod(x,0)      DOMAIN  x       y       EDOM
-remainder(x,0) DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
+remainder(x,0) DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
 .TE
 .SH ATTRIBUTES
 For an explanation of the terms used in this section, see

(Also attached.)

If the foregoing looks ugly, bear in mind that you're wandering a bit
off the path with these comments.

tbl(1):
Limitations
     Within a tbl region (except in text blocks or on roff control
     lines), avoid escape sequences that read the rest of the input
     line, as \" and \! do.

> > I was able to get a complete, successful check with the following
> > command.
> > 
> > $ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle
> 
> Thanks!  Would you mind sending a formal patch set?  =)

I'll need a reminder when I feel less swamped (after groff 1.25.0,
likely), or someone else can steal my fixes.  :)

> > I needed to override `NROFFFLAGS` because of a new warning category
> > in the forthcoming groff 1.25.
> > 
> > groff NEWS:
> > *  The formatter supports a new warning category, "style".  It is
> >    used to diagnose input that is non-idiomatic or likely to produce
> >    an unexpected result (or none at all), but is not invalid.
> > 
> > One of the things it warns about is failure to break an input line
> > after the end of a sentence is detected.  The Linux man-pages may
> > want to disable that warning category by default until those have
> > been cleaned up.  Enabling it will, of course, permit machine-driven
> > identification of sites requiring such cleanup, which has to date
> > been tedious, requiring manual inspection or application of regexes
> > that can be thwarted by the *roff language's context-dependent
> > grammar.
> 
> We'll see when it arrives.  :)

Yeah, I wouldn't want to fool with it before it lands in an official
release, either.  But this _does_ mean that the Linux man-pages
documents will appear to "regress" suddenly when the host system
upgrades to groff 1.25.0, because you use `-ww` to turn on all warnings.

$ git grep -n -B4 '[-]ww' share
share/mk/configure/build-depends/groff-base/nroff.mk-32-DEFAULT_NROFFFLAGS ::= \
share/mk/configure/build-depends/groff-base/nroff.mk-33-        -T$(NROFF_OUT_DEVICE) \
share/mk/configure/build-depends/groff-base/nroff.mk-34-        -rLL=$(NROFF_LINE_LENGTH)n \
share/mk/configure/build-depends/groff-base/nroff.mk-35-        -rCHECKSTYLE=$(NROFF_CHECKSTYLE_LVL) \
share/mk/configure/build-depends/groff-base/nroff.mk:36:        -ww

At 2026-10-19T20:32:27+0200, Hugo Buddelmeijer wrote:
> On 10/19/26 15:02, G. Branden Robinson wrote:
> > Hi Alex & Hugo,
> > 
> > At 2026-10-19T08:20:29+0200, Alejandro Colomar wrote:
> > > > Date: 2026-10-17 21:19:22+0200
> > > > From: Hugo Buddelmeijer <hugo@buddelmeijer.nl>
> > > > Running `make -R check` fails because the text in futex_waitv.2
> > > > and console_codes.4 is too wide.
> > [...]
> > I observe that the failure doesn't tell you why the "check" target
> > is failing.  It simply says "GREP" and then the output of grep
> > itself.  We are not informed what grep was looking for.
> 
> For me the output of `make -R check` was useful enough (using groff
> 1.24.0, should have included that):
> 
> .tmp/man/man4/console_codes.4:750: warning: table wider than line
> length minus indentation
> 
> It does not exactly say which line is too long, so I removed
> 'suspicious' lines until the test passed, then added them back one by
> one, adding a text block whenever TROFF complained.

That's a good approach.  Because of the way the tbl preprocessor and the
formatter (troff) interact, it's hard to emit a precise diagnostic here;
the information isn't just lying around to be abstracted.  There might
be a way we can enhance tbl to keep track of which table cell was
responsible for causing the table to extend to its maximum width,
however.[1]  That width _is_ tracked, in the register `TW`.

tbl(1):
   roff interface
     The register TW stores the width of the table region in basic
     units; it can’t be used within the region itself, but is defined
     before the .TE token is output so that a troff macro named TE can
     make use of it.  ...

> 5 lines were to wide for the table.
> 
> The result looks rather unsatisfactory, see attached screenshot, which
> shows the affected table and the one above it.  The top one is much
> broader.

Yes.  tbl uses a formula to compute the default width of text blocks.

tbl(1):
   Text blocks
...
     If w or x modifiers are not specified for all columns of a text
     block’s span, the default length of the text block (more precisely,
     the line length used to process the text block’s diversion) is
     computed as L×C/(N+1), where L is the current line length, C the
     number of columns spanned by the text block, and N the number of
     columns in the table.  ...

> I investigated a bit deeper, and believe that the table is so narrow
> because it uses column specification "l l."; replacing that with "l
> lx." makes the table wider (probably requiring less text blocks).
> This was just cargo-culted from other tables though.

That's a good fix.  It's orthogonal to the use of text blocks, though;
on a wide terminal, applying the 'x' column modifier will quieten the
warning, but won't make the table format better on narrower terminals.
Those will still get the warning, and worse, the table will overset.

Regards,
Branden

[1] In fact, that's a good enough idea that I'll file a Savannah ticket
    for it after I have a URL for a publicly archived form of this
    message I can cross-reference.

[-- Attachment #1.2: matherr.3.diff --]
[-- Type: text/x-diff, Size: 1739 bytes --]

diff --git a/man/man3/matherr.3 b/man/man3/matherr.3
index 2e179e358..8711ee3cd 100644
--- a/man/man3/matherr.3
+++ b/man/man3/matherr.3
@@ -200,9 +200,9 @@ .SS Math functions that employ matherr()
 acos(|x|>1)	DOMAIN	HUGE	y	EDOM
 asin(|x|>1)	DOMAIN	HUGE	y	EDOM
 atan2(0,0)	DOMAIN	HUGE	y	EDOM
-acosh(x<1)	DOMAIN	NAN	y	EDOM	\" retval is 0.0/0.0
-atanh(|x|>1)	DOMAIN	NAN	y	EDOM	\" retval is 0.0/0.0
-atanh(|x|==1)	SING	(x>0.0)?	y	EDOM	\" retval is x/0.0
+acosh(x<1)	DOMAIN	NAN	y	EDOM\" retval is 0.0/0.0
+atanh(|x|>1)	DOMAIN	NAN	y	EDOM\" retval is 0.0/0.0
+atanh(|x|==1)	SING	(x>0.0)?	y	EDOM\" retval is x/0.0
 \ 	\ 	HUGE_VAL :
 \ 	\ 	\-HUGE_VAL
 cosh(fin) o/f	OVERFLOW	HUGE	n	ERANGE
@@ -237,15 +237,15 @@ .SS Math functions that employ matherr()
 \ 	\ 	HUGE_VAL,x)
 log(0)	SING	\-HUGE	y	EDOM
 log(x<0)	DOMAIN	\-HUGE	y	EDOM
-log2(0)	SING	\-HUGE	n	EDOM	\" different from log()
-log2(x<0)	DOMAIN	\-HUGE	n	EDOM	\" different from log()
+log2(0)	SING	\-HUGE	n	EDOM\" different from log()
+log2(x<0)	DOMAIN	\-HUGE	n	EDOM\" different from log()
 log10(0)	SING	\-HUGE	y	EDOM
 log10(x<0)	DOMAIN	\-HUGE	y	EDOM
 pow(0.0,0.0)	DOMAIN	0.0	y	EDOM
 pow(x,y) o/f	OVERFLOW	HUGE	n	ERANGE
 pow(x,y) u/f	UNDERFLOW	0.0	n	ERANGE
 pow(NaN,0.0)	DOMAIN	x	n	EDOM
-0**neg	DOMAIN	0.0	y	EDOM	\" +0 and -0
+0**neg	DOMAIN	0.0	y	EDOM\" +0 and -0
 neg**non-int	DOMAIN	0.0	y	EDOM
 scalb() o/f	OVERFLOW	(x>0.0) ?	n	ERANGE
 \ 	\ 	HUGE_VAL :
@@ -253,7 +253,7 @@ .SS Math functions that employ matherr()
 scalb() u/f	UNDERFLOW	copysign(	n	ERANGE
 \ 	\ 	\ \ 0.0,x)
 fmod(x,0)	DOMAIN	x	y	EDOM
-remainder(x,0)	DOMAIN	NAN	y	EDOM	\" retval is 0.0/0.0
+remainder(x,0)	DOMAIN	NAN	y	EDOM\" retval is 0.0/0.0
 .TE
 .SH ATTRIBUTES
 For an explanation of the terms used in this section, see

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

Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-10-19 17:41:45-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
[...]
> > 	diff --git i/GNUmakefile w/GNUmakefile
> > 	index 9f3ced6f461b..9b480fe5e52c 100644
> > 	--- i/GNUmakefile
> > 	+++ w/GNUmakefile
> > 	@@ -16,6 +16,7 @@ endif
> > 	 MAKEFLAGS += --no-builtin-rules
> > 	 MAKEFLAGS += --no-builtin-variables
> > 	 MAKEFLAGS += --warn-undefined-variables
> > 	+MAKEFLAGS += --silent
> > 	 
> > 	 
> > 	 ifndef srcdir
> > 	@@ -66,5 +67,4 @@ help:
> > 	 
> > 	 
> > 	 .DELETE_ON_ERROR:
> > 	-.SILENT:
> > 	 FORCE:
> > 
> > and it seems to work.  If you use --no-silent on the command line, it
> > overrides the default.  I'll check better before committing.
> 
> Cool!

Committed and released.  :-)

[...]
> > I'd love a formal patch, especially with a good commit message.  :)
> 
> I'm sure.  But I'm dealing with yet another late-release-cycle fire
> drill in groff right now, unfortunately.

I'm patient.  MR.sed made me learn.  :p

[...]
> And on second thought it occurs to me that you may not want that column
> in the table after all, since they are all *roff comments intended (I
> think) only for inspection by the document maintainer, not by the
> reader.  In that case what you want to do is not add a column, but stop
> supplying excess table entries--in other words, discard the tab
> character before the `\"` comment escape sequence.

Yes, and no.

> diff --git a/man/man3/matherr.3 b/man/man3/matherr.3
> index 2e179e358..8711ee3cd 100644
> --- a/man/man3/matherr.3
> +++ b/man/man3/matherr.3
> @@ -200,9 +200,9 @@ .SS Math functions that employ matherr()
>  acos(|x|>1)    DOMAIN  HUGE    y       EDOM
>  asin(|x|>1)    DOMAIN  HUGE    y       EDOM
>  atan2(0,0)     DOMAIN  HUGE    y       EDOM
> -acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> -atanh(|x|>1)   DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> -atanh(|x|==1)  SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
> +acosh(x<1)     DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> +atanh(|x|>1)   DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> +atanh(|x|==1)  SING    (x>0.0)?        y       EDOM\" retval is x/0.0

It was certainly more readable with the tab.  Would a couple of spaces
be okay?  Or will they produce spurious space too that might fail?

[...]
> 
> (Also attached.)
> 
> If the foregoing looks ugly, bear in mind that you're wandering a bit
> off the path with these comments.
> 
> tbl(1):
> Limitations
>      Within a tbl region (except in text blocks or on roff control
>      lines), avoid escape sequences that read the rest of the input
>      line, as \" and \! do.

Hmmm.

> > > I was able to get a complete, successful check with the following
> > > command.
> > > 
> > > $ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle
> > 
> > Thanks!  Would you mind sending a formal patch set?  =)
> 
> I'll need a reminder when I feel less swamped (after groff 1.25.0,
> likely), or someone else can steal my fixes.  :)

Okay.  Do you have an estimate of when I should poke you?  As in maybe
one month or two?

> > > I needed to override `NROFFFLAGS` because of a new warning category
> > > in the forthcoming groff 1.25.
> > > 
> > > groff NEWS:
> > > *  The formatter supports a new warning category, "style".  It is
> > >    used to diagnose input that is non-idiomatic or likely to produce
> > >    an unexpected result (or none at all), but is not invalid.
> > > 
> > > One of the things it warns about is failure to break an input line
> > > after the end of a sentence is detected.  The Linux man-pages may
> > > want to disable that warning category by default until those have
> > > been cleaned up.  Enabling it will, of course, permit machine-driven
> > > identification of sites requiring such cleanup, which has to date
> > > been tedious, requiring manual inspection or application of regexes
> > > that can be thwarted by the *roff language's context-dependent
> > > grammar.
> > 
> > We'll see when it arrives.  :)
> 
> Yeah, I wouldn't want to fool with it before it lands in an official
> release, either.  But this _does_ mean that the Linux man-pages
> documents will appear to "regress" suddenly when the host system
> upgrades to groff 1.25.0, because you use `-ww` to turn on all warnings.

If you're willing to spend some time on helping me address the
diagnostics by improving the pages, that's fine.  :)

> $ git grep -n -B4 '[-]ww' share
> share/mk/configure/build-depends/groff-base/nroff.mk-32-DEFAULT_NROFFFLAGS ::= \
> share/mk/configure/build-depends/groff-base/nroff.mk-33-        -T$(NROFF_OUT_DEVICE) \
> share/mk/configure/build-depends/groff-base/nroff.mk-34-        -rLL=$(NROFF_LINE_LENGTH)n \
> share/mk/configure/build-depends/groff-base/nroff.mk-35-        -rCHECKSTYLE=$(NROFF_CHECKSTYLE_LVL) \
> share/mk/configure/build-depends/groff-base/nroff.mk:36:        -ww


Have a lovely night!
Alex

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

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

Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[G. Branden Robinson]

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

Hi Alex,

At 2026-10-23T20:06:01+0200, Alejandro Colomar wrote:
> > Date: 2026-10-19 17:41:45-0500
> > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> > > If you use --no-silent on the command line, it overrides the
> > > default.  I'll check better before committing.
> > 
> > Cool!
> 
> Committed and released.  :-)

Good stuff!

> > > I'd love a formal patch, especially with a good commit message.
> > > :)
> > 
> > I'm sure.  But I'm dealing with yet another late-release-cycle fire
> > drill in groff right now, unfortunately.
> 
> I'm patient.  MR.sed made me learn.  :p

I learned from it too.

Some news on that front.  Would you be willing to stage the roll-out
of this transition?  The syscalls(2) page is what broke us before--you
wanted extensive annotations to my sed scripts.  (Not unreasonable, but
demanding of further effort on my part.)  The rest seemed easy.  Maybe
if we can migrate:

1.  everything but syscalls(2) first; then
2.  migrate syscalls(2) in multiple passes, each of 1 sed script, each
    showing no change in the formatting of rendered text.

I think users and readers will enjoy (and could have been enjoying) a
major benefit to their man page browsing experience even with only step
1 done.  Now that GNU less has its own OSC 8 interpreter and
appropriately equipped versions are making it into distributions, the
power of man page hyperlinking is easy to see.  Literally, even, with
even more recent changes to apply underlining to hyperlinked character
cells.  The latest version of less, v712, released this past week, even
defaults to "less -R".[0]  A future I dreamed of in 2018 is finally
arriving.

In other news, Oracle finally did a thing I once thought they had done
in Solaris 11, then had to correct my understanding about, and then had
to re-correct myself again.

About 2½ years ago, in SRU66 (a kind of service pack), an update to
Solaris 11.4, Oracle completely discarded their AT&T System V troff.
It's _gone_.  What replaced it?  groff 1.23.0--which supports groff
man's `MR` macro.[1]

They kept some auxiliary stuff like checkeq(1) and checkmm(1) (neither
of which GNU eqn or groff mm need, since they internally implement more
generous diagnostics than their AT&T implementations).  And they
implemented a bunch of wrappers to force preconv(1) into execution
pipelines.

So between groff >= 1.23.0 and, well, the _next_ release of mandoc(1)--
any day now, it's to be hoped--support for `MR` will be nearly
universal.

I didn't ever expect mandoc's release cadence to become slower than
groff's!

> > And on second thought it occurs to me that you may not want that
> > column in the table after all, since they are all *roff comments
> > intended (I think) only for inspection by the document maintainer,
> > not by the reader.  In that case what you want to do is not add a
> > column, but stop supplying excess table entries--in other words,
> > discard the tab character before the `\"` comment escape sequence.
> 
> Yes, and no.
> 
> > diff --git a/man/man3/matherr.3 b/man/man3/matherr.3
> > index 2e179e358..8711ee3cd 100644
> > --- a/man/man3/matherr.3
> > +++ b/man/man3/matherr.3
> > @@ -200,9 +200,9 @@ .SS Math functions that employ matherr()
> >  acos(|x|>1)    DOMAIN  HUGE    y       EDOM
> >  asin(|x|>1)    DOMAIN  HUGE    y       EDOM
> >  atan2(0,0)     DOMAIN  HUGE    y       EDOM
> > -acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > -atanh(|x|>1)   DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > -atanh(|x|==1)  SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
> > +acosh(x<1)     DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> > +atanh(|x|>1)   DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> > +atanh(|x|==1)  SING    (x>0.0)?        y       EDOM\" retval is x/0.0
> 
> It was certainly more readable with the tab.  Would a couple of spaces
> be okay?  Or will they produce spurious space too that might fail?

The problem is that you'll still have a comment escape sequence in a
table entry.  Since groff 1.24.0, GNU tbl warns about that (unless the
comment escape sequence occurs in a text block, where these escape
sequenced don't cause problems).  Unfortunately groff 1.24.x produce an
extra warning diagnostic in this case that is not helpful.  I just
discovered that while composing this email and have scheduled a fix for
groff 1.25.0.[2]

$ ./build/test-groff -tz -W style -m an -T utf8 ../man-pages/man3/matherr.3
tbl:../man-pages/man3/matherr.3:240: warning: comment escape sequence '\"' in entry "EDOM\" different from log()"
tbl:../man-pages/man3/matherr.3:241: warning: comment escape sequence '\"' in entry "EDOM\" different from log()"
tbl:../man-pages/man3/matherr.3:248: warning: comment escape sequence '\"' in entry "EDOM\" +0 and -0"
troff:../man-pages/man3/matherr.3:203: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:204: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:205: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:240: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:241: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:248: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
troff:../man-pages/man3/matherr.3:256: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
../man-pages/man3/matherr.3:199: warning: table wider than line length minus indentation

The riot of delimiter warnings is the havoc that use of a comment escape
sequence in a (non-text-block) table entry creates.

I added that warning in groff 1.24.0 because without it, a user is
unlikely to comprehend what is supposed to be wrong with their table.

Or they would have been uncomprehending, had they enabled warnings in
category "delim", which were not on by default.  In groff 1.25.0, they
will be.

> [...]
> > 
> > (Also attached.)
> > 
> > If the foregoing looks ugly, bear in mind that you're wandering a
> > bit off the path with these comments.
> > 
> > tbl(1):
> > Limitations
> >      Within a tbl region (except in text blocks or on roff control
> >      lines), avoid escape sequences that read the rest of the input
> >      line, as \" and \! do.
> 
> Hmmm.

This is a consequence of how tbl works.  It generates *roff `\w` escape
sequences bracketing the table entry contents so that the formatter can
compute their rendered widths.  Without font metrics, tbl cannot do that
itself.

My recommendation is to move these "inline" comments to precede what
they document.

-acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
+.\" retval is 0.0/0.0
+acosh(x<1)     DOMAIN  NAN     y       EDOM

> > > > I was able to get a complete, successful check with the
> > > > following command.
> > > > 
> > > > $ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle
> > > 
> > > Thanks!  Would you mind sending a formal patch set?  =)
> > 
> > I'll need a reminder when I feel less swamped (after groff 1.25.0,
> > likely), or someone else can steal my fixes.  :)
> 
> Okay.  Do you have an estimate of when I should poke you?  As in maybe
> one month or two?

Say, two weeks after groff 1.25.0 final, which I'll announce here as
usual.  By then I should know if the release was a triumph, a disaster
(and therefore will be keeping me busy), or met with the usual stony
indifference.

> > Yeah, I wouldn't want to fool with it before it lands in an official
> > release, either.  But this _does_ mean that the Linux man-pages
> > documents will appear to "regress" suddenly when the host system
> > upgrades to groff 1.25.0, because you use `-ww` to turn on all
> > warnings.
> 
> If you're willing to spend some time on helping me address the
> diagnostics by improving the pages, that's fine.  :)

I don't doubt it.  I have a lot of irons in man page fires!

Regards,
Branden

[0] https://github.com/gwsw/less/commit/7f46e9ff46216f3e560cd1f41ddf3b36b11eec0e
[1] https://blogs.oracle.com/solaris/whats-new-in-oracle-solaris-114-sru-66

    That blog entry doesn't make any _note_ of this change, but it's
    there.  I have been able to examine it at cfarm.net.

    Also, there's this evidence:

    http://pkg.oracle.com/solaris/release/en/search.shtml?token=groff&action=Search

[2] https://savannah.gnu.org/bugs/?68825

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

Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-10-23 15:32:16-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
[...]
> 
> > > > I'd love a formal patch, especially with a good commit message.
> > > > :)
> > > 
> > > I'm sure.  But I'm dealing with yet another late-release-cycle fire
> > > drill in groff right now, unfortunately.
> > 
> > I'm patient.  MR.sed made me learn.  :p
> 
> I learned from it too.
> 
> Some news on that front.  Would you be willing to stage the roll-out
> of this transition?

Certainly!  One major problem from your script was that it was huge and
difficult to understand.  Partial scripts will be significantly simpler.

>  The syscalls(2) page is what broke us before--you
> wanted extensive annotations to my sed scripts.

Actually, I would have preferred a pipeline of one-liner commands,
without having to be a sed(1) expert to understand it.  Something like
the implementation of sortman(1) would be great.

>  (Not unreasonable, but
> demanding of further effort on my part.)  The rest seemed easy.  Maybe
> if we can migrate:
> 
> 1.  everything but syscalls(2) first; then

Sure; as long as the commit message says something like "we're leaving
syscalls(2) --and only syscalls(2)-- out of this transition, because
it's way more complex than the rest", I'd take it.

> 2.  migrate syscalls(2) in multiple passes, each of 1 sed script, each
>     showing no change in the formatting of rendered text.

Yup.

> I think users and readers will enjoy (and could have been enjoying) a
> major benefit to their man page browsing experience even with only step
> 1 done.  Now that GNU less has its own OSC 8 interpreter and
> appropriately equipped versions are making it into distributions, the
> power of man page hyperlinking is easy to see.  Literally, even, with
> even more recent changes to apply underlining to hyperlinked character
> cells.  The latest version of less, v712, released this past week, even
> defaults to "less -R".[0]  A future I dreamed of in 2018 is finally
> arriving.
> 
> In other news, Oracle finally did a thing I once thought they had done
> in Solaris 11, then had to correct my understanding about, and then had
> to re-correct myself again.
> 
> About 2½ years ago, in SRU66 (a kind of service pack), an update to
> Solaris 11.4, Oracle completely discarded their AT&T System V troff.
> It's _gone_.  What replaced it?  groff 1.23.0--which supports groff
> man's `MR` macro.[1]

Wow!  :-)

> 
> They kept some auxiliary stuff like checkeq(1) and checkmm(1) (neither
> of which GNU eqn or groff mm need, since they internally implement more
> generous diagnostics than their AT&T implementations).  And they
> implemented a bunch of wrappers to force preconv(1) into execution
> pipelines.
> 
> So between groff >= 1.23.0 and, well, the _next_ release of mandoc(1)--
> any day now, it's to be hoped--support for `MR` will be nearly
> universal.

Very please CC Ingo in that patch.  :)

> I didn't ever expect mandoc's release cadence to become slower than
> groff's!

Heh!

> > > And on second thought it occurs to me that you may not want that
> > > column in the table after all, since they are all *roff comments
> > > intended (I think) only for inspection by the document maintainer,
> > > not by the reader.  In that case what you want to do is not add a
> > > column, but stop supplying excess table entries--in other words,
> > > discard the tab character before the `\"` comment escape sequence.
> > 
> > Yes, and no.
> > 
> > > diff --git a/man/man3/matherr.3 b/man/man3/matherr.3
> > > index 2e179e358..8711ee3cd 100644
> > > --- a/man/man3/matherr.3
> > > +++ b/man/man3/matherr.3
> > > @@ -200,9 +200,9 @@ .SS Math functions that employ matherr()
> > >  acos(|x|>1)    DOMAIN  HUGE    y       EDOM
> > >  asin(|x|>1)    DOMAIN  HUGE    y       EDOM
> > >  atan2(0,0)     DOMAIN  HUGE    y       EDOM
> > > -acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > > -atanh(|x|>1)   DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> > > -atanh(|x|==1)  SING    (x>0.0)?        y       EDOM    \" retval is x/0.0
> > > +acosh(x<1)     DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> > > +atanh(|x|>1)   DOMAIN  NAN     y       EDOM\" retval is 0.0/0.0
> > > +atanh(|x|==1)  SING    (x>0.0)?        y       EDOM\" retval is x/0.0
> > 
> > It was certainly more readable with the tab.  Would a couple of spaces
> > be okay?  Or will they produce spurious space too that might fail?
> 
> The problem is that you'll still have a comment escape sequence in a
> table entry.  Since groff 1.24.0, GNU tbl warns about that (unless the
> comment escape sequence occurs in a text block, where these escape
> sequenced don't cause problems).  Unfortunately groff 1.24.x produce an
> extra warning diagnostic in this case that is not helpful.  I just
> discovered that while composing this email and have scheduled a fix for
> groff 1.25.0.[2]

We can wait for 1.25.0.

> $ ./build/test-groff -tz -W style -m an -T utf8 ../man-pages/man3/matherr.3
> tbl:../man-pages/man3/matherr.3:240: warning: comment escape sequence '\"' in entry "EDOM\" different from log()"
> tbl:../man-pages/man3/matherr.3:241: warning: comment escape sequence '\"' in entry "EDOM\" different from log()"
> tbl:../man-pages/man3/matherr.3:248: warning: comment escape sequence '\"' in entry "EDOM\" +0 and -0"
> troff:../man-pages/man3/matherr.3:203: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:204: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:205: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:240: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:241: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:248: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> troff:../man-pages/man3/matherr.3:256: warning: missing closing delimiter in width computation escape sequence; expected special character or class 'tbl', got a newline [-w delim]
> ../man-pages/man3/matherr.3:199: warning: table wider than line length minus indentation
> 
> The riot of delimiter warnings is the havoc that use of a comment escape
> sequence in a (non-text-block) table entry creates.
> 
> I added that warning in groff 1.24.0 because without it, a user is
> unlikely to comprehend what is supposed to be wrong with their table.
> 
> Or they would have been uncomprehending, had they enabled warnings in
> category "delim", which were not on by default.  In groff 1.25.0, they
> will be.

I trust you to send me your best patch, because I don't know what to do
with it.  If you think the best thing is to juts remove the tabs, I
guess I could live with it.

> 
> > [...]
> > > 
> > > (Also attached.)
> > > 
> > > If the foregoing looks ugly, bear in mind that you're wandering a
> > > bit off the path with these comments.
> > > 
> > > tbl(1):
> > > Limitations
> > >      Within a tbl region (except in text blocks or on roff control
> > >      lines), avoid escape sequences that read the rest of the input
> > >      line, as \" and \! do.
> > 
> > Hmmm.
> 
> This is a consequence of how tbl works.  It generates *roff `\w` escape
> sequences bracketing the table entry contents so that the formatter can
> compute their rendered widths.  Without font metrics, tbl cannot do that
> itself.
> 
> My recommendation is to move these "inline" comments to precede what
> they document.
> 
> -acosh(x<1)     DOMAIN  NAN     y       EDOM    \" retval is 0.0/0.0
> +.\" retval is 0.0/0.0
> +acosh(x<1)     DOMAIN  NAN     y       EDOM

Not a fan of this.  Maybe just remove the tabs.  Or maybe we want to
print these in the table as a new column?

> > > > > I was able to get a complete, successful check with the
> > > > > following command.
> > > > > 
> > > > > $ make -R check NROFF_LINE_LENGTH=80 NROFFFLAGS=-Wstyle
> > > > 
> > > > Thanks!  Would you mind sending a formal patch set?  =)
> > > 
> > > I'll need a reminder when I feel less swamped (after groff 1.25.0,
> > > likely), or someone else can steal my fixes.  :)
> > 
> > Okay.  Do you have an estimate of when I should poke you?  As in maybe
> > one month or two?
> 
> Say, two weeks after groff 1.25.0 final, which I'll announce here as
> usual.  By then I should know if the release was a triumph, a disaster
> (and therefore will be keeping me busy), or met with the usual stony
> indifference.

Ok.

> > > Yeah, I wouldn't want to fool with it before it lands in an official
> > > release, either.  But this _does_ mean that the Linux man-pages
> > > documents will appear to "regress" suddenly when the host system
> > > upgrades to groff 1.25.0, because you use `-ww` to turn on all
> > > warnings.
> > 
> > If you're willing to spend some time on helping me address the
> > diagnostics by improving the pages, that's fine.  :)
> 
> I don't doubt it.  I have a lot of irons in man page fires!

:-)


Have a lovely night!
Alex

> 
> Regards,
> Branden
> 
> [0] https://github.com/gwsw/less/commit/7f46e9ff46216f3e560cd1f41ddf3b36b11eec0e
> [1] https://blogs.oracle.com/solaris/whats-new-in-oracle-solaris-114-sru-66
> 
>     That blog entry doesn't make any _note_ of this change, but it's
>     there.  I have been able to examine it at cfarm.net.
> 
>     Also, there's this evidence:
> 
>     http://pkg.oracle.com/solaris/release/en/search.shtml?token=groff&action=Search
> 
> [2] https://savannah.gnu.org/bugs/?68825



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

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