From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43158 invoked by alias); 11 Aug 2019 09:33:28 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 43149 invoked by uid 89); 11 Aug 2019 09:33:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Those, Sorry X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.133) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 11 Aug 2019 09:33:24 +0000 Received: from [192.168.178.45] ([95.91.209.168]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MpCz1-1iesTW3zn5-00qn8Y for ; Sun, 11 Aug 2019 11:33:22 +0200 Subject: Re: [ITP] italic-man To: cygwin-apps@cygwin.com References: <80003dc4-e484-543b-befe-3b3db8d3c1d6@towo.net> <875zn6uq0h.fsf@Rainer.invalid> <7ea1dcb2-70bc-9a74-e5a3-0be55f85d7fa@towo.net> From: Thomas Wolff Message-ID: <05f12d5f-3cb8-e331-a7ee-7fa5812218d8@towo.net> Date: Sun, 11 Aug 2019 09:33:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-08/txt/msg00033.txt.bz2 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!