From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Hugo Buddelmeijer <hugo@buddelmeijer.nl>, linux-man@vger.kernel.org
Subject: Re: table layout in console_codes.4 (was: `make -R check` fails due to futex_waitv.2 and console_codes.4 being too wide)
Date: Fri, 23 Oct 2026 20:06:01 +0200 [thread overview]
Message-ID: <atugtpm0SfMnnTYj@debian> (raw)
In-Reply-To: <20261019224145.aovalqyh2fpcdzdk@illithid>
[-- 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 --]
next prev parent reply other threads:[~2026-10-23 18:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2026-10-23 20:32 ` G. Branden Robinson
2026-10-23 21:16 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atugtpm0SfMnnTYj@debian \
--to=alx@kernel.org \
--cc=g.branden.robinson@gmail.com \
--cc=hugo@buddelmeijer.nl \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox