public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Thomas Wolff <towo@towo.net>
To: cygwin-apps@cygwin.com
Subject: Re: [ITP] italic-man
Date: Sun, 11 Aug 2019 09:33:00 -0000	[thread overview]
Message-ID: <05f12d5f-3cb8-e331-a7ee-7fa5812218d8@towo.net> (raw)
In-Reply-To: <e0788452-b10f-f673-a43e-687c5e4e2df8@SystematicSw.ab.ca>


Am 11.08.2019 um 00:29 schrieb Brian Inglis:
> 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?
I checked the man-db postinstall script, and it does not overwrite 
man_db.conf if it exists already, so the modification will persist.
> Is a permanent postinstall script provided to maintain the conf on man-db updates?
Not needed under the observation above. If it were, how would a 
permanent postinstall be deployed?
Thanks,
Thomas

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

  reply	other threads:[~2019-08-11  9:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-28  6:01 Thomas Wolff
2019-08-09 12:59 ` Jon Turney
2019-08-09 15:07   ` Ken Brown
2019-08-09 18:56   ` Achim Gratz
2019-08-09 19:31     ` Thomas Wolff
2019-08-09 20:51       ` Brian Inglis
2019-08-10  9:07         ` Thomas Wolff
2019-08-10 21:39           ` Thomas Wolff
2019-08-10 22:29           ` Brian Inglis
2019-08-11  9:33             ` Thomas Wolff [this message]
2019-08-11 16:17               ` Achim Gratz
2023-01-21 17:04 Thomas Wolff
2023-02-16 18:59 ` Jon Turney
2023-02-16 19:17   ` Thomas Wolff
2023-06-21 21:45     ` Thomas Wolff
2023-06-25 13:36       ` Jon Turney
2023-06-25 13:59         ` Thomas Wolff
2023-06-25 16:02           ` ASSI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05f12d5f-3cb8-e331-a7ee-7fa5812218d8@towo.net \
    --to=towo@towo.net \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).