Subject: Re: Colour curses programs now default to white on black
To: Julian Coleman <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 08/07/2002 07:49:30
Greg: I think you're making incorrect assumptions. The text you quote says
that the default initial background colour is "assumed" to be black. It
does not say that the start_color() function will set the background
colour to be black. It does not say the foreground colour will be set
Julian: I still read it as start_color() restores the initial values. The
initial background colour is assumed to be black. Thus, <something> on
black is what color-using programs should expect, as that is what
start_color() will restore the colours to.
*** I think Greg's spot on, here. The background colour is assumed to be
*** black because that's what many physical terminals are; such is not the
*** case for, e.g., a virtual terminal such as a xterm, rterm, aterm, Eterm,
*** Think of it this way, to restate: A terminal that is plugged into a
*** serial port is, by default, white on black, or light grey on black, more
*** likely. This is the "most relaxed visible state" of a terminal. Black
*** on white on such terminals is not a very friendly picture.
*** virtual terminals, of course, are not under such restrictions as they
*** were designed to be used with a true graphic interface where appearance
*** is much more important. So "background colour is assumed to be black"
*** does not apply.
Greg: I don't know what your change will do to 'links', but currently it is
_really_ badly misbehaved if you tell it to use color, especially if
you're using xterm -- suddenly everything is white on black even if the
terminal is configured to show black on white by default. This is very
disconcerting and very unfriendly.
*** Agree strongly here.
Julian: OK, so I've installed links. It displays as black on white in my
xterms (which are -fg black -bg white). More investigation. Ah! It
doesn't use curses at all. So, it won't affect it at all.
Greg: An ANSI standard terminal (including xterm if I understand things
correctly) can be set to use its default colours by sending the
sequence: ESC [ 3 9 m ESC [ 4 9 m (or its shortened form).
The only thing start_color() should do, if it does anything at all, is
to send this sequence. IIRC in a terminfo based curses implementation
the string given by the 'orig_pair', or 'op' capability would be sent.
According to the SysVR4 manuals this corresponds to the 'op' termcap
capability, but NetBSD's termcap(5) doesn't define that one....
Julian: Oversight. 'oc' and 'op' are now in termcap(5). Using the above sequence
(SGR0?) is the way that ncurses implements use_default_colors() (from
reading the documentation). However, not all xterms have that capability.
Thus, our xterm termcap entry has 'op=\E[m', which is turn off all
attributes. It does restore the terminal default colours though.
*** I would think this would be fine for our purposes, especially considering
*** that I, for one, actually tune my "sixteen colours" appropriately to
*** my own tastes and do not want them redefined on me. This is as
*** unfriendly to me as assuming my background colour is black.
Greg: Actually Some termainals may also need 'oc' to be sent in order to
reset all the color-pairs to their original values too....
Julian: Yes, but not xterm, vtnnn, etc.
Greg: BTW, quoting the SysVR4 curs_color(3x) manual page:
It also restores the colors on the terminal to the values they had
when the terminal was just turned on.
Note in particular the last sentence.
Julian: Noted. It's pretty much the same as above. Just missing the
"background colour is assumed to be black" part.
*** "Assume" is three words.
Greg: Perhaps your confusion stems from the strange xterm confusion where with
16-colour support disabled
Julian: Hmm, I didn't think I was confused. But, I definitely wasn't confused
about this. Anyway, at the moment, we don't support 16 colour xterms.
The 'AB' and 'AF' entries need fixing for colours greater than 8 and our
termcap parser needs extending to support that (both on my list).
*** Agree here.
Greg: If you look in NetBSD's xsrc/xc/programs/xterm/terminfo you'll find that
'op' is now (correctly) defined as "\E[39;49m". Indeed the 'termcap'
file in the same directory also defines an 'op' termcap capability with
the same sequence.
Julian: If you look at src/share/termcap/termcap.src, you'll see "op=\E[m".
*** If ESC [ m doesn't restore to default foreground/background OF THE
*** TERMINAL IN QUESTION (i.e. black/light grey for physical terminals,
*** or the originally specified -fg/-bg, if any, for [axE]term/rxvt),
*** _it_ _is_ _broken_.
*** Similarly if colour curses is wont to force the background colour to
*** black, _it_ _is_ _broken_. What if my default settings are black/grey?
*** If my background gets set to black, my text becomes invisible. If it
*** forces my foreground to grey, it's essentially reversed what I wanted.
*** This is not acceptable and is tantamount to having delivered me an
*** oven when I asked for a freezer, and I'd ask you to take it back
*** and give me my blasted freezer, thank you.
NetBSD: Get Over It.