[ On Wednesday, August 7, 2002 at 11:07:04 (+0100), Julian Coleman wrote: ]
> Subject: Re: Colour curses programs now default to white on black
>
> > 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.

Then you are most definitely reading it very incorrectly.

"assumed to be black" means only that the standard assumes the user has
set the default background colour to be black.  Why this assumption is
so important to note is not made clear, and as far as I can see not even
hinted about.  No further explanation or rationale is given and no other
function or feature seems to depend on the default background colour
(and how one could even do so is well beyond my grasp).  It seems
entirely irrelevant.

It most definitely does not mean that curses will change the default
background colour.  This is extremely well clarified in the SysVR4
documentation from which the standard is _directly_ derived.

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

The question is about set_color(), not use_default_colors().

BTW, they are "SGR39" and "SGR49".  SGR0 is "ESC [ 0 m" (for xterm and
ANSI terminals anyway).

Though I could try to test the reference implementation and describe its
results, perhaps this wee bit of code from a certain start_color.c will
serve the purpose better.  These are the only blocks in that routine
containing tputs() calls.

    if (can_change)
    {
       /* initialize color_tbl with the following colors: black, blue, */
       /* green, cyan, red, magenta, yellow, black.  if table has more */
       /* than 8 entries, use the same 8 colors for the following 8    */
       /* positions, and then again, and again ....   If table has less*/
       /* then 8 entries, use as many colors as will fit in.           */

       for (i=0; i<COLORS; i++)
       {    j = i%8;

        if (j%2)
            color_tbl[i].b = 1000;
	else
            color_tbl[i].b = 0;

        if ((j%4) > 1)
            color_tbl[i].g = 1000;
	else
            color_tbl[i].g = 0;

        if (j > 3)
            color_tbl[i].r = 1000;
	else
            color_tbl[i].r = 0;
       }

       tputs (orig_colors, 1, _outch);
    }

    tputs (tparm (orig_pair), 1, _outch);

    /* for Tek terminals set the background color to zero */

    if (set_background)
    {
    	tputs (tparm (set_background, 0), 1, _outch);
	SP->_cur_pair.background = 0;
	SP->_cur_pair.foreground = -1;
    }

I didn't know about the last bit with set_background to '0' until I
looked just now, but it seems irrelevant given the comment above it.

(note the variable names are identical to those documented in terminfo(4))

(note also that the terminfo file for xtermc as distributed in all
SysVR3 and SysVR4 implementations I've seen does not contain a string
definition for "setb", nor do any of the ANSI compatible colour
terminals)

>  However, not all xterms have that capability.
> Thus, our xterm termcap entry has 'op=\E[m', which is turn off all
> attributes.

More correctly it should be 'op=\E[0m', though perhaps the subtle
differences in how that sequence is interpreted are not present in the
NetBSD xterm (or maybe even not in any xterm).

BTW, I've always assumed the /usr/share/misc/termcap.src entry to be
incorrect in all places where it differs from xsrc/xc/programs/xterm/termcap

If that's not true then the latter must be fixed.

>  It does restore the terminal default colours though.

If that is true then set_color() will not set a black background, will
it?  (at least not unless that's the way the user configured the
terminal in the first place) (and it seems to be true from my reading of
the code in charproc.c, though I'm not 100% sure what a colour value of
'-1' means....)

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

hmmm... do you mean using the likes of "%?"?

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>