> From: http://www.opengroup.org/onlinepubs/007908799/xcurses/intov.html#tag_001_005_002
> 
> The initial input mode for Curses operations is unspecified  unless the implementation supports Enhanced Curses compliance, in which the initial input mode is cbreak mode. 
> 
> (Every version I've ever used starts in 'cooked' mode.)

Snag is that programs assuming current ncurses behaviour won't call cbreak().

> IMHO curses ought to treat colour changes as noops is start_color() fails.

Yes, it should.  It works at the moment, but we should probably return ERR
when a colour pair is set and the terminal doesn't support colour.  I'll
check what Solaris does for this (e.g. when called with colour plus another
attribute).

> >   it deletes the items[0] window and then tries to delete the sub-windows of

> Clearly broken program behaviour....

Indeed.  But, should we cope with it?  We could do what Solaris does:

     The delwin() routine deletes the named window,  freeing  all
     memory associated with it. Subwindows must be deleted before
     the main window can be deleted.

and just ERR the delwin() for the main window.  With a change to how we
handle nextp and orig, we could also handle nested sub-windows (see PR
lib/32417 (NetBSD curses subwindow support is broken.)).

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/