Subject: Re: Colour curses programs now default to white on black
To: NetBSD current-users mailing list <email@example.com>
From: Julian Coleman <firstname.lastname@example.org>
Date: 08/07/2002 11:07:04
> 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
My other computer also runs NetBSD