At 2026-01-21T23:11:48+0000, Pádraig Brady wrote: > I was about post that snapshot, and this was actually what stopped me. > I am really reluctant to introduce new config into the world, > so had an idea to reuse the common TERM=dumb setting, > rather than HELP_NO_MARKUP=anything. I can't see why > one might want to disable --help markup independently of TERM setting.
Speaking as a contributor to ncurses's man pages, I think that's a good
idea.
I'm aware of the "NO_COLOR" initative[1], which "*_NO_MARKUP" reminds me
of, but I don't think it's a great idea because I think it's probably
not necessary.
For one thing, people who don't want "color" in the output from the
text-stream oriented programs probably don't want other kinds "graphical
rendition" styling, like bold or underline or italics, even if these
aren't changes to "color". Let alone do they want other kinds of
ECMA-48 escape sequence like OSC, or SOS, or APC, or PM.
To be fair, the "NO_COLOR" initiative, as of this writing, restricts
itself purely to the suppression of color configuration.
Q. Why not just set $TERM to dumb or xterm without color
support?
A. ... It is reasonable to configure certain software such as a
text editor to use color or other ANSI attributes sparingly
(such as the reverse attribute for a status bar) while still
desiring that other software not add color unless configured to.
Q. Should the presence of NO_COLOR disable other styling such as
bold, underline, and italic?
A. No. This standard only signals the user’s intention regarding
adding ANSI color to text output.
I recently had a "vigorous discussion" with Gavin Smith of the Texinfo
project on this issue.[2]
grotty(1), groff's output driver for terminals, doesn't currently pay
any attention to `TERM`, but it easily could. I'm happy to add support
to grotty, interpreting TERM=dumb as a synonym for its "-cbou" options.
I've pronounced a C/C++ code freeze[3] (barring release-critical bugs
therein) since I'm trying to get groff 1.24 over the finish line,[4] but
I can give this issue some priority when groff 1.25 development opens.
I want to release 1.25 this summer, because feature goals for releases
wear me out.
Or bust the freeze for it if people persuade me that it's an emergency.
It would also be straightforward to make `NO_COLOR` in the environment a
synonym for grotty's `-c` option if the initiative really catches fire.
`GROFF_NO_SGR` is already there and does the same thing. (Strictly,
grotty would "go too far" per the Q&A's above, but at present that
doesn't concern me. You ask for monochrome, you get it.)
Regards,
Branden
[1] https://no-color.org/
[2] https://lists.gnu.org/archive/html/bug-texinfo/2026-01/msg00023.html
[3] https://lists.gnu.org/archive/html/groff/2026-01/msg00000.html
[4] https://lists.gnu.org/archive/html/info-groff/2026-01/msg00000.html
signature.asc
Description: PGP signature
