Subject: Re: Colour curses programs now default to white on black
To: Julian Coleman <jdc@coris.demon.co.uk>
From: Greywolf <greywolf@starwolf.com>
List: current-users
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
 at all.

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,
*** whatever...

*** 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".
  See above.

*** 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.

				--*greywolf;
--
NetBSD: Get Over It.