Folks, This started out innocuously enough, I picked up a PR about fileobj from pkgsrc not working properly. This was partially an upstream problem but also an issue with our curses chgat() function. After a bit of digging I found two things. Firstly, every other colour capable implementation of curses seems to use colour pair 0 as the default colour - our implementation set the default pair to the last pair. Secondly, without looking at our libcurses code and exploiting access to a static variable there is simply no way of actually using the default colour pair in our libcurses. Given these findings I embarked on changing the default colour pair number to be 0. This actually turned out to be a lot harder than it first seems because the refresh code used a colour pair of 0 to mean "don't apply colour at all" along with a bunch of initialisation issues where the initial colour set wouldn't happen. After a bit of rework I have all the curses tests passing (some output is different now of course) and using the updated code seems to work fine. Certainly, the original issue with fileobj is gone. The reason I am putting this out here is that there are now some visual differences, mainly with the colour of the background. In some curses applications the assume_default_colors extension is used and the colours set to -1 (another curses extension that means "no colour"). Previously in NetBSD curses this had no effect, the terminal remained in white foreground and black background but now this request is honoured the terminal default colour scheme is used.
So, the point of all this blather is even though there have been no interface changes as a result of my work there is the potential for a significant visual change. Should I mark this with a libcurses major bump? I don't think it necessary but I am putting it out there for discussion... -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
