* `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide @ 2026-10-17 19:19 Hugo Buddelmeijer 2026-10-19 6:20 ` Alejandro Colomar 0 siblings, 1 reply; 9+ messages in thread From: Hugo Buddelmeijer @ 2026-10-17 19:19 UTC (permalink / raw) To: Alejandro Colomar; +Cc: linux-man [-- 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide 2026-10-17 19:19 `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide Hugo Buddelmeijer @ 2026-10-19 6:20 ` Alejandro Colomar 2026-10-19 13:02 ` 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 0 siblings, 1 reply; 9+ messages in thread From: Alejandro Colomar @ 2026-10-19 6:20 UTC (permalink / raw) To: Hugo Buddelmeijer; +Cc: linux-man, g.branden.robinson [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-19 6:20 ` Alejandro Colomar @ 2026-10-19 13:02 ` G. Branden Robinson 2026-10-19 16:55 ` Alejandro Colomar 2026-10-19 18:32 ` table layout in console_codes.4 Hugo Buddelmeijer 0 siblings, 2 replies; 9+ messages in thread From: G. Branden Robinson @ 2026-10-19 13:02 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Hugo Buddelmeijer, linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-19 13:02 ` 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 @ 2026-10-19 16:55 ` Alejandro Colomar 2026-10-19 18:32 ` table layout in console_codes.4 Hugo Buddelmeijer 1 sibling, 0 replies; 9+ messages in thread From: Alejandro Colomar @ 2026-10-19 16:55 UTC (permalink / raw) To: G. Branden Robinson; +Cc: Hugo Buddelmeijer, linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 2026-10-19 13:02 ` 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 2026-10-19 16:55 ` Alejandro Colomar @ 2026-10-19 18:32 ` Hugo Buddelmeijer 2026-10-19 22:41 ` 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 1 sibling, 1 reply; 9+ messages in thread From: Hugo Buddelmeijer @ 2026-10-19 18:32 UTC (permalink / raw) To: G. Branden Robinson, Alejandro Colomar; +Cc: linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-19 18:32 ` table layout in console_codes.4 Hugo Buddelmeijer @ 2026-10-19 22:41 ` G. Branden Robinson 2026-10-23 18:06 ` Alejandro Colomar 0 siblings, 1 reply; 9+ messages in thread From: G. Branden Robinson @ 2026-10-19 22:41 UTC (permalink / raw) To: Alejandro Colomar, Hugo Buddelmeijer; +Cc: linux-man [-- 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 --] ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-19 22:41 ` 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 @ 2026-10-23 18:06 ` Alejandro Colomar 2026-10-23 20:32 ` G. Branden Robinson 0 siblings, 1 reply; 9+ messages in thread From: Alejandro Colomar @ 2026-10-23 18:06 UTC (permalink / raw) To: G. Branden Robinson; +Cc: Hugo Buddelmeijer, linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-23 18:06 ` Alejandro Colomar @ 2026-10-23 20:32 ` G. Branden Robinson 2026-10-23 21:16 ` Alejandro Colomar 0 siblings, 1 reply; 9+ messages in thread From: G. Branden Robinson @ 2026-10-23 20:32 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Hugo Buddelmeijer, linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide) 2026-10-23 20:32 ` G. Branden Robinson @ 2026-10-23 21:16 ` Alejandro Colomar 0 siblings, 0 replies; 9+ messages in thread From: Alejandro Colomar @ 2026-10-23 21:16 UTC (permalink / raw) To: G. Branden Robinson; +Cc: Hugo Buddelmeijer, linux-man [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-10-23 21:16 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-10-17 19:19 `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide Hugo Buddelmeijer 2026-10-19 6:20 ` Alejandro Colomar 2026-10-19 13:02 ` 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 2026-10-19 16:55 ` Alejandro Colomar 2026-10-19 18:32 ` table layout in console_codes.4 Hugo Buddelmeijer 2026-10-19 22:41 ` 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 2026-10-23 18:06 ` Alejandro Colomar 2026-10-23 20:32 ` G. Branden Robinson 2026-10-23 21:16 ` Alejandro Colomar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
![[-- Attachment #2: man-console-pages.png --] [-- Type: image/png, Size: 44777 bytes --]](../../1e4d35e5-f8af-402b-9cdb-46a70f793b96@buddelmeijer.nl/2-man-console-pages.png){kind=link}