From owner-freebsd-arch Fri Oct 18 8:48:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B26A637B406; Fri, 18 Oct 2002 08:48:30 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0BEA43EB2; Fri, 18 Oct 2002 08:48:29 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9IFmSpk049536; Fri, 18 Oct 2002 09:48:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 18 Oct 2002 09:48:01 -0600 (MDT) Message-Id: <20021018.094801.123456703.imp@bsdimp.com> To: ru@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: color, again, in grotty From: "M. Warner Losh" In-Reply-To: <20021018095026.GA3386@sunbay.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021018095026.GA3386@sunbay.com> Ruslan Ermilov writes: : : > Well, if the SGR escapes are on by default, I'd think you do need to : : > consider the effects that will have on popular terminals. AFAIK, : : > even the majority of xterm versions don't support colors, outside : : > the GNU/Linux world. : : : : The eternal question whether we shall follow a standard or not... : : ISO 6429 is from 1991 -- isn't eleven years enough to wait? vt100 escape sequences have been known since 1980, 20 years! They are the defact terminal emulation escape sequence, why not code all programs to use them? Because although standardized, they are still device dependent. They are just one way to encode that information, not the only way. : : > Didn't you say that you also use SGR for bold and underline? That : : > would produce similar problems for terminals whose bold and : : > underline commands are not SGR, right? : : : : Do you think there are terminals which have SGR sequences for : : activating colors and non-SGR sequences for activating bold and : : underline? : : If you read the thread, I am pretty sure you will get the same feeling : as I am -- it is that the new ANSI SGR escapes became the new standard : for TTY-type output devices serviced with grotty(1), and nroff(1). : Our default pager (less/more) also supports this feature through the : -R option, as does the new -R option in the new info(1). I know that there sre terminals for which the SGR sequences screw things up. I had to deal with a raft of Televideo terminals back in the day that we were constantly finding stupid programmers who hard coded things to vt100 and we had to keep fixing the stupid programs because those programmers couldn't be bothered to use curses. I find this to be an analogous case. Back in the day, one could have argued that since all terminals understood vt100 sequences, we should have stored our man pages in vt100 escape sequences? Well, vt100s are almost impossible to find and live on only as emulation and most terminals no longer are only vt100, but some are close (cons25, for example, dies on some vt100 sequences). Back in the day, vt100's were claimed to be ANSI compliant terminals, which is also a standard. Yet, we didn't standardize on them because the nice thing about standards is that there are so many to choose from. So this whole argument that it is standard is a little bogus. : We have also learned one pitfall with this new approach. Our default : terminal driver, syscons(4), renders the "underscore" attribute, SGR : E[4m (see screen(4)), the same as bold, which is the (code documented) : bug, so using this new SGR scheme directly as it comes with new Groff : worsens the output on cons25* type terminals. On the other hand, : classical nroff(1) filters like ul(1) (and not by accident less(1)) : render underlining with the "reverse" attribute on terminals that do : not support underlining, like cons25. So we must either fix syscons(4) : or to somehow tell grotty(1) to emit old sequences to print bold and : italic characters. I have prepared and sent the patch to Groff : maintainers that tells grotty(1) to use the old scheme for printing : bold and italic characters, but otherwise have color output enabled. : Today I have tried a different approach ("fixing" the driver), and : was surprised by the unexpected good results -- I have changed the : syscons(4) so that it renders "underscore" with "reverse", and I : can now differentiate all three bold (bold attr), italic (underline : attr), and bold+italic (bold+underline attrs) fonts (and colors!) : on a cons25 TTY. That proves my point more. Just because these escape sequences are a standard, they are not the only way to go. 'Fixing' syscons will actually break legacy programs, which is bad and not really an option. Especially because it is to be compatible with a dubious standard from the Linux world. Bah humbug. If you want a linux comaptible console, write one, don't coopt FreeBSD. : There are three ways we can go here: : : 1. Disable SGR support for grotty(1). : : It can be soft-disabled by setting GROFF_NO_SGR in environment, : or hard-disabled system-wide (like it is now in -CURRENT as of : this writing) in /usr/share/tmac/troffrc. I like this option. SGR belongs not in groff, but in ul, et al. : 2. Stay compatible with the new standard (11 years old ANSI std). : This means we fix syscons(4) so that it renders "underscore" : distinguishable from "bold", and change the default pager to : "more -R". There will still be an option of soft-disabling : it for those who want it disabled. I don't like this option. Fixing syscons is silly and will break compatibility with the past. The standard is just 'a' standard, not THE standard like you get with posix or ansi-c. There are many other legitimate ways of doing things and moving to device dependence because someone takes a shining to a standard is not a wise move. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message