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

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

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.

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

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.

> Acutally Some termainals may also need 'oc' to be sent in order to reset
> all the color-pairs to their original values too....

Yes, but not xterm, vtnnn, etc.

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

Noted.  It's pretty much the same as above.  Just missing the "background
colour is assumed to be black" part.

> Perhaps your confusion stems from the strange xterm confusion where with
> 16-colour support disabled 

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

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

If you look at src/share/termcap/termcap.src, you'll see "op=\E[m".  See
above.

J

-- 
                    My other computer also runs NetBSD
                          http://www.netbsd.org/