On 2019-08-10 03:07, Thomas Wolff wrote:
> Am 09.08.2019 um 22:51 schrieb Brian Inglis:
>> On 2019-08-09 13:31, Thomas Wolff wrote:
>>> Am 09.08.2019 um 20:56 schrieb Achim Gratz:
>>>> Jon Turney writes:
>>>>> This gets a GTG from me.
>>>>> I believe that according to our stated procedures additional approvals
>>>>> are required, because this package is unique to cygwin.
>>>> I'm not sure I remember correctly from when the discussion went on the
>>>> first time, but wasn't there some mumbling about this partly going into
>>>> groff?  If that's still the case, remind me what this would entail and
>>>> I'll look into it.
>>> There are multiple ways of activating the feature (also described in the man
>>> page).
>>> The previous strategy placed a shell script wrapper "groff" aside groff, so the
>>> groff script and groff.exe would coexist in /bin. This was tricky to install and
>>> particularly it reportedly did not survive a package update of groff.
>>> The new approach does not use this wrapper anymore. Instead it redirects nroff
>>> to the package-supplied iroff script by configuration in /etc/man_db.conf.

How are updates to man-db, /etc/man_db.conf etc. handled?
Is a permanent postinstall script provided to maintain the conf on man-db updates?

>> There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars
>> (see attached - must be sourced from profile or rc) to remap bold, underline,
>> etc. into italic and/or colour, or whatever else you want to change, in all less
>> output.
> So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls
> should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do?

Those settings affect all *less* output, not just *man*.
Some people can't stand any colours (white on black was good enough for my
grandfather...) the same as I couldn't wait for decent fonts, graphics, and
colour support on something other than plotters, like displays and printers, and
then for files.
Options are good, to allow users to choose where and what is affected, and how.

Sorry, been messing around with colours, fonts, graphics, and SGR sequences so
much, that I can't remember what led to what. You need the reset sequences also.
Set GROFF_NO_SGR=1 to pass old bold/italic overstrikes thru for less to
colourize - looks like if GROFF_NO_SGR just exists it works:

	$ LESS_TERMCAP_md=$(tput bold)$(tput setaf 4) \
	LESS_TERMCAP_me=$(tput sgr0) \
	LESS_TERMCAP_us=$(tput sitm)$(tput setaf 4) \
	LESS_TERMCAP_ue=$(tput ritm)$(tput sgr0) \
	GROFF_NO_SGR= man man

bold is also bright blue, underline is shown as italic in blue: the attached now
sets these up in the env.

Other uses of SGR sequences are in e.g.:
	$ GREP_COLORS='mt=0;33;44;1;7:ln=34' grep -bnHi color ~/.bash*
which on mt matches resets SGR, then sets fg colour yellow, background blue,
enables bold, then reverses those colours, to display bold blue on bright
yellow, line numbers in green, defaulting file names to magenta, and byte counts
in blue; also e.g.:
	$ \
GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'\
	gcc -g -Og -Wall -Wextra -c mintty_config.c

as I run black fg text in white bg windows, and bright yellow fg warnings are
invisible; just like blue fg messages in black bg windows, most combos of
magenta and red, and many of cyan and green: those similar hues should be
unmappable pairs in any colour palette!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.