From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 Description of problem: Enabling reverse video mode from the VT Options menu (ctrl + middle mousebutton) leaves cursor black together with background being black as well, making the cursor invisible. Version-Release number of selected component (if applicable): xterm-208-2.FC4 How reproducible: Always Steps to Reproduce: 1. start xterm 2. turn on "Enable Reverse Video" from the VT Options menu 3. Actual Results: Cursor colour is same as the background colour (both black). Expected Results: Earlier versions made the cursor colour different, white if I recall correctly. Additional info: [joyr@doors ~]$ xrdb -query | grep -i curs *Scrollbar*Cursor: left_ptr *Scrollbar*cursorName: left_ptr Emacs*cursorColor: Orchid Xcursor.size: 24 Xcursor.theme: Bluecurve Xcursor.theme_core: true [joyr@doors ~]$
Seconded, in a slightly different situation. I use a white-on-black set of defaults, and my cursor always turns black at some point (turning on reverse video exposes the cursor). This didn't happen in xterm-208-1. $ xrdb -query | grep VT100 *VT100*backarrowKey: false *VT100*background: black *VT100*boldColors: true *VT100*boldFont: false *VT100*boldMode: off *VT100*colorBDMode: off *VT100*colorBLMode: off *VT100*colorULMode: off *VT100*cursorColor: grey *VT100*dynamicColors: false *VT100*eightBitInput: false *VT100*foreground: grey *VT100*geometry: 80x24 *VT100*jumpScroll: true *VT100*loginShell: true *VT100*ptyInitialErase: true *VT100*reverseWrap: true *VT100*saveLines: 2500 *VT100*scrollBar: true *VT100*underLine: on *VT100*utf8: true
Yes, I see the problem - this is because of the fix to bug 178302, which was a complaint about xterm not setting the cursor color if *vt100*cursorColor is explicitly set to be the same as the foreground color . xterm was testing if the cursorColor is the same as the foreground color, and not setting the cursor to that color if so. But when ReverseVideo is enabled, the cursor color IS the same as the foreground color by default, so xterm would not set the cursor color to that value, leaving it the same as the background. I think xterm's logic needs to be a bit more sophisticated than just refusing to set the cursorColor if it is the same as the foreground . Perhaps xterm should only refuse to set the cursorColor to the foreground if ReverseVideo is in effect. I'll be fixing this with xterm-208-4.FC4 today .
Something more complicated than what you're suggesting, but taking that into account. I've had a couple other complaints about this recently, will look into a short #210 to address this area.
Looked into it - no: the bug is in a different place (changing set_cursor_gcs is incorrect). I'll add a call to set_cursor_gcs from ReverseVideo instead. Looks like this was an old bug exposed by the changes to set_cursor_gcs rather than a new bug.
Many thanks Thomas - placed a call to set_cursor_gcs in ReverseVideo and the problem is now fixed with xterm-208-4.FC4 , shortly to be released to FC-4 updates / testing.
From User-Agent: XML-RPC xterm-208-4.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
xterm-208-4.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.