Subject: Re: xterm v. xterm-old
To: None <firstname.lastname@example.org>
From: Geoff Wing <email@example.com>
Date: 02/08/2001 14:56:34
Alan Barrett <firstname.lastname@example.org> typed:
:> 7 Feb 2001 07:02:37 GMT, Geoff Wing sez:
:> > % printf '\e[m\e[1m\e[33m\e[44mHello\e[K\e[m\n'
:What results should one expect from that if everything is working
:On a raw text console (NetBSD-1.5R/i386, wscons with WSEMUL_VT100,
:TERM=wsvt25), where normal text is white on black, I print that string
:and get "Hello" in yellow on blue as I would expect, but all the space
:between the last printed character and the right hand edge of the screen
:changes from black background to blue background. The next line is
:white on black as usual.
:If I repeat the experiment with "screen" inside the wscons text console
:(screen-3.9.8 from pkgsrc, TERM=screen), then I still get "Hello" in
:yellow on blue, but the trailing space up to the end of line remains in
:the original background colour (black), instead of changing to blue.
The ESC [ K sequence in the printf statement above puts all characters
to the right of "Hello" into the erased state.
xterm and rxvt, and screen 3.9.8 with the bce command (or defbce) implement
a newer colour model where erased characters take on the current graphic
rendition - so background colour is preserved. Older terminals and emulators
tend to give erased characters the default graphic rendition, i.e. the
default background colour. BTW, screen (in old colour model mode) will
give quirky results if you try to do that in a term which implements
the new colour model.
There's no standard here. ISO6429:1992 p82 says the representation of the
erased state is implementation dependent.
Geoff Wing : <email@example.com>
Rxvt Stuff : <firstname.lastname@example.org>
Zsh Stuff : <email@example.com>