Re: Man page customization after 1.23?

[Nate Bargmann]

* On 2023 08 Jul 18:17 -0500, G. Branden Robinson wrote:
> Hi Ronan,
> 
> At 2023-07-08T21:03:03+0000, Ronan Pigott wrote:
> [LESS_TERMCAP_*]
> > I wrote:
> > > Today I learned such a feature exists. Despite Mark Nudelman having had
> > > up to 39 years to document it, apparently the only place the feature is
> > > described is on StackExchange.[...]
> > 
> > Indeed, it went many years undocumented in less. In more recent
> > versions there is a nod to this feature in the less(1) man page:
> > 
> >    LESS_TERMCAP_xx
> >        Where "xx" is any two characters, overrides the definition
> >        of the termcap "xx" capability for the terminal.
> 
> Ah.  I'm still on less 581.2, and haven't looked at anything later.
> I'm glad something's shown up!
> 
> > > I'd say more that it is an unforeseen consequence of a deliberate
> > > change. However, it appears to be that you can get the feature back
> > > by switching grotty(1) back to legacy/overstriking output as opposed
> > > to SGR output.
> > 
> > Ok. For now I've decided to export MANROFFOPT="-c" along with MANPAGER.
> 
> One potentially annoying caveat is that if you ever use man(1)'s `-T`
> option to format for something _other_ than a terminal device, you will
> need to clear the "-c" out of that environment variable, because other
> output drivers like grops(1) and gropdf(1) don't understand it.
> 
> My understanding is that relatively few people ever use man(1) to do
> anything but render man pages to a terminal, though.  Which is kind of a
> shame...
> 
> > > SGR output was _already_ the default in groff 1.22.4 (and for some
> > > time before that), so this change was not actually recent. But if
> > > you have replaced a distributor's groff build with your own from
> > > source, or if your distributor has decided to accept the upstream
> > > default use of SGR, then that could explain why the LESS_TERMCAP_*
> > > trick suddenly stopped working.
> > 
> > Are you certain about this?
> 
> Some distributors have overridden this upstream default.  As far as I
> know, Debian was the first to do so; Ubuntu inherited it (or perhaps the
> other way around, as the same person has long maintained the groff
> package for both), and then other distributions cargo-culted it into
> their own groff packages.

I see that Arch Linux is still carrying the line in its
/usr/share/groff/site-tmac/man.local|mandoc.local files even with
version 1.23:

.  \" Shut off SGR by default (groff colors)
.  \" Require GROFF_SGR envvar defined to turn it on
.  if '\V[GROFF_SGR]'' \
.    output x X tty: sgr 0


As a test I commented those two lines on an Arch system I have and also
commented all LESS_TERMCAP_* lines in my ~/.bashrc, closed and opened a
new terminal session and I don't see any difference compared to before
my editing.  It appears to me that the lines in man.local and any
setting of LESS_TERMCAP_* are to none effect with 1.23 until '-c' is
passed to the output driver.

> [In the course of writing this email, we received a bug report against
> groff because apparently some hack to make Vim work as a man pager
> assumes that grotty(1) will operate in overstriking mode.  My money's
> on it being this same problem of a local patch slipping in a device
> control command.]

I did a quick test of the vimpager package yesterday.  According to its
docs all overstriking is removed.  Then it apparently applies its own
heuristics for coloring the page using the color scheme set in vim.
This, after discovering that the package supplied in Arch is
incompatible with Vim 9 and thus I had to test with a Git checkout of
vimpager.  The Vim 9 support was added in late 2022 but the latest
release of the package was made in 2015 which Arch ships.  With vimpager
the intent of the man page author WRT emphasis in the running text is
almost completely ignored.  I went back to using less as the pager.

I found there are other methods of using Vim as a man pager but did not
test them.  If those methods also result in the overstriking being
removed, I doubt this is much of an issue for Groff.

> One thing I should clarify is that I anticipated a refactoring of
> grotty(1) to use terminfo(3) as enabling us to kill off the
> "GROFF_NO_SGR" variable, whereas I also said in reply to you that I had
> no plans to kill off the variable.  This sounds contradictory.
> 
> What I did not talk about was time scales.  Given the grief around this
> issue, I think it might be a good idea to retain "GROFF_NO_SGR" for a
> release, at least to throw a diagnostic about how grotty(1) uses
> terminfo(3) now, and if people want Western Electric Teletype Model 37
> emulation they should set $TERM accordingly.

Being able to set colors and other text attributes through grotty via
terminfo seems like a nice long term plan.  It seems this would allow
for highlighting more elements separately besides the emphasis provided
by the page author.  I suspect that a slim majority of those reading man
pages on a screen are doing so on a color monitor these days.  ;-)

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

signature.asc
Description: PGP signature