Date: Fri, 18 Oct 2002 09:48:01 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ru@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021018.094801.123456703.imp@bsdimp.com> In-Reply-To: <20021018095026.GA3386@sunbay.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021018095026.GA3386@sunbay.com>
Ruslan Ermilov <ru@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021018.094801.123456703.imp>