Date: Mon, 21 Oct 2002 10:38:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: "Andrey A. Chernov" <ache@nagual.pp.ru>, "M. Warner Losh" <imp@bsdimp.com>, arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <3DB43BAD.AAB55A1A@mindspring.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote: > > Pagers can't tell the difference between an escape sequence that > > results in characters which are not displayable without the > > escape sequence (and therefore take a character cell on the screen) > > and those which manipulate display attributes (and therefore do not > > take any screen space) from those which do cursor positioning in > > place of "CR/LF" (e.g. "delete line" at the top of the page is > > equivalent to scrolling) vs. those which do nothing apparent. > > Look at the -R option of less(1). The point I was trying to make is > that the use of isatty(3) is no help here, because even if grotty(1) > took the libtermcap(3) approach, the output would almost never be a > TTY. That's easy: you can not interpose a pager between you and the terminal. If you impose a pager, you are screwed. That leaves you the option of not paging, or integrating the pager into grotty. > > Therefore, it's unreasonable to run processed data through a > > pager, if the results of that processing include terminal > > implementation dependent escape sequences.. > > > > The way this is normally dealt with is to use "_^HX" for underscore, > > "X^HX" for bold, etc., utilizing "overstrike", and have the pager > > convert it based on the pager's knowledge of the terminal display > > sequences from the termcap. > > This only covers _attributes_, but not color sequences, which are > the Subject: here. While we can still use an old scheme to produce > device-independent sequences for attributes, we lose the color > support completely: FreeBSD's man(1) will be black-n-white forever. That's exactly right: you don't get color, unless your termcap 'standout', 'underline' or other attribute is set to a color escape sequence. I think what you are complaining about here is that your termcap interpretation is not indirected through another layer that does mapping of attributes to foreground/background/attribute tuples. Frankly, if you want to implement this, the place to do it is in your cgetcap(3) implementation. > Definitely not me. I have been involved into the development of > the at386 compatible terminal back in early 90's. I also worked > on Esprit 400 terminals which were vt100 based. > > So far nobody told me what would be the correct alternative way to > support colors in grotty(1). 1) Integrate your pager as an option in grotty(1). 2) Support attribute mapping in the pager, and make grotty put out the standard overstrike sequences, which a pager then interprets via an attribute mapping table, due to the base implementation of cgetent returing colors or anything else you map them to for 'standaout', 'underline', etc. 3) Don't support color. > It became apparent to me that grotty(1) cannot use > libtermcap, because it never knows what TERM it will be displayed > on -- quite often the grotty(1) output is saved for future reference > (e.g., in the form of catpages). Then I guess it doesn't get color, since termcap is the only legal method of obtaining color. > Such an alternative would be to > write a filter (similar to or extending the functionality of ul(1)) > that would be capable of parsing the ANSI SGR attribute/color > sequences and translate them to the right sequences for a given > output device, or to strip them off completely. Both ul(1) and colcrt(1) are moderately bogus, in this regard, unless they are treated as output filters for a pager, rather than input. The yardstick one should use here is "Can I use it with 'vi'?"; that very quickly identifies what you should and should not be considering as solutions. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB43BAD.AAB55A1A>