Re: lib/55220: Possible color problem in curses and/or py-curses

[Brett Lymn <blymn%internode.on.net@localhost>]

On Tue, Oct 26, 2021 at 09:10:01AM +0000, Thomas Klausner wrote:
>  
>  The position where I'm at is reverse (in my case, gray on black). When
>  I move the cursor, the new byte under the cursor position gets that
>  color scheme, but the old one keeps it (it stays gray on black). I
>  don't think this is intended behaviour.
>  
>  Can you please check that?
>  

I agree, I don't think this is intended but I don't think it is a curses
problem.  If I run this test code:

#!/usr/pkg/bin/python3.8
#
import curses

stdscr = curses.initscr()
curses.start_color()

win = curses.newwin(20, 80, 0, 0)

win.addstr(0, 0, "Current testing", curses.A_UNDERLINE)
win.getch()

curses.init_pair(1, curses.COLOR_RED, curses.COLOR_WHITE)
curses.init_pair(2, curses.COLOR_GREEN, curses.COLOR_WHITE)
win.addstr(1, 0, "Color testing", curses.color_pair(1))
win.getch()

win.chgat(1, 3, 4, curses.color_pair(2))
win.getch()

curses.endwin()

Then the win.chgat call results in the 4 characters are set to a black
background with white writing (default colour pair) instead of green on
a white background.  Ramping up the debug in curses I see:

1638479121.598015: mvwchgat: x: 3 y: 1 count: 4 attr: 0x0 color pair 0

Which is also what I see when running debug on fileobj too - the
attributes and colour are _always_ 0 which translates to attribute
A_NORMAL and white text on a black background.  Having a look at the
py-curses library code in the chgat handling there is:


    color = (short)((attr >> 8) & 0xff);
    attr = attr - (color << 8);


This really doesn't map well to the NetBSD curses colour and attributes
so it isn't surprising that the NetBSD curses is always getting 0's.

So, it looks like the py-curses needs to be fixed.

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