Re: Man page customization after 1.23?

[Ronan Pigott]

>> After updating to 1.23 I can no longer change the color of man pages
>> with LESS_TERMCAP_* vars.
> 
> 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.[1]

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.

and a subset of the feature was exposed in a flag -D. Despite the description,
and though I haven't looked too thoroughly, it is my understanding less relies
on overstricken output to implement this feature, just as you mention.

> 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.

> 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? I don't see any corresponding change in
https://gitlab.archlinux.org/archlinux/packaging/packages/groff. I have been
blindly using this Arch package for years. IIUC the invocation from
/usr/bin/man is:

    groff -Tutf8 -mtty-char -mandoc

and I can tell that the groff provided by 1.22.4 has overstricken output when I
reinstall the older package, while 1.23.0 groff does not.

> One of the things I'd like to do for groff 1.24 is make grotty(1) use
> terminfo(3) to employ terminal capabilities, instead of assuming
> a terminal is either a typewriter ("-c") or an ISO 6429 terminal
> (default). https://savannah.gnu.org/bugs/?63583
> 
> If that is implemented, a side effect is that you could achieve this
> color customization simply by redefining the corresponding terminfo
> entries. You could then do so globally, affecting all uses of bold and
> italic (as such, not counting applications that blindly write ISO 6429
> escape sequences as groff, GNU ls, and Bash do) to the terminal, for
> instance, not just those that grotty writes.

Are you certain about those too? AFAIK ls color usually comes from LS_COLORS,
which has the values embedded. They might contain dumb escapes but there's no
reason LS_COLORS couldn't be generated based on a terminfo db.

Also, I think bash/readline uses ncurses impl of termcap's tgetstr to get at
terminfo db. A user's bashrc certainly might contain hard coded escapes, but as
they are user supplied they will presumably be correct for their chosen term at
least.

There is room for user error in both cases, but they are at least adjustable.
Any software that emits such escapes without configuration or terminfo is
probably an outlier today.

> If you still wanted such a color scheme particularized to the rendering
> of man pages with grotty(1), you could make an alternate terminal
> definition (using a capability like "use=xterm-256color" to incorporate
> another by reference, most likely), and then write a shell function or
> shell script to wrap the man(1) command, applying the alternate terminal
> definition only then.
> 
> Does any of this hold any promise, in your view?

Yes, I think using a terminfo db is a good direction for groff. I admittedly
don't really grok groff all that well but maybe it would be possible for man to
change the rendering of man pages by redefining some macros like .B and .I?
With either that or a custom terminfo db, man-db has both $MANOPT and a user
configuration file that could then be used to configure this hypothetical
feature.