Re: Man page customization after 1.23?

[G. Branden Robinson]

Hi Ronan,

At 2023-07-08T08:46:40+0000, Ronan Pigott wrote:
> 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]

> It seems like this in an intentional change, and I understand that it
> is a bit of a hack.

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

$ type groff
groff is /home/branden/bin/groff
$ groff --version | tail -n 1
GNU troff (groff) version 1.23.0
$ groff -Tascii -man -P -c  ./build/src/preproc/eqn/neqn.1 \
  | LESS_TERMCAP_md=$(tput bold; tput setaf 2) less -R

When I do the foregoing, bold material shows up in bold green.

> But how can the output of man be customized post 1.23?

It can be customized in several ways--see the "Options" section of the
groff_man(7) man page.  However, supported rendering options do not
include the customization of markup colors.

When I try to think about how this less(1) feature must work, I am a bit
puzzled.  It seems impossible to me that it knows what termcap
capabilities are being requested by the application writing to the
terminal.  I have to guess that this feature is something that is
coupled with less(1)'s overstricken output interpreter, which means it
will not be fully general with respect to terminal capabilities.

> Only with GROFF_NO_SGR?

For now, with respect to the colorization of bold and underline output
from grotty(1) with this LESS_TERMCAP_* feature, it looks like the
answer is "yes".  (Or, as shown above, by getting the "-c" option to
grotty(1).)  But see below...

> Is it planned to deprecate that too in the future?

No.

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.

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?

Regards,
Branden

[1] 
https://unix.stackexchange.com/questions/108699/documentation-on-less-termcap-variables

signature.asc
Description: PGP signature