Description of problem: I have a customized color scheme in xterm (yellowish on black), with a screen hardstatusline in the last line. The hardstatusline has a blue background color. Since the switch to 208-1 the text cursor color is blue (the same as the hardstatusline) instead of the same color as the normal text (yellowish) like it was before. Explicitly setting the cursorColor in .Xresources does not help either. Version-Release number of selected component (if applicable): xterm-208-1 How reproducible: Always Steps to Reproduce: 1. start an xterm with a screen hardstatusline 2. 3. Actual results: Cursor color is the bgcolor of the hardstatusline Expected results: Cursor color should be the fg color Additional info:
How do are you running xterm with the 'hardstatusline' ? A special $TERM setting? Which one ? Having just tried to set the xterm cursorColor Xresource, only setting 'xterm*cursorColor: #xxxxxx' worked - setting XTerm.cursorColor, or just 'cursorColor:', had no effect.
The hardstatusline is not set by xterm but by the "screen" running inside it. The config line in .screenrc is hardstatus alwayslastline "%{yb} [ %H ] %{gb} %0c:%s | %d.%m.%Y %{rb} %l %{gb} %w " My .Xresources (Xterm settings only) is XTerm*background: black XTerm*foreground: #F1CE1C XTerm*cursorColor: #F1CE1C XTerm*scrollBar: false XTerm*geometry: 160x63 XTerm*font: -*-fixed-bold-r-normal-*-14-*-*-*-*-*-iso10646-1
cursorColor is under the VT100 widget, so XTerm.cursorColor cannot work. The cursor color has (for quite a while) adapted to be the reverse of the ANSI colors when it's placed on top of a colored cell. Some applications are careless about turning colors off when they're not in use, so the cursor can be colored even on a "blank" cell. Perhaps that is what is being reported here.
I've just confirmed that this is "NOTABUG" - when the XTerm.vt100.cursorColor resource is specified, then the cursor color is always set to that color, including when running 'screen' with the hardstatus line specified above in .screenrc.
I just upgraded to screen-4.0.2-11.1, xterm-208-1.1, created a new user, copied the .screenrc and .Xresources attached below into the new user's home, logged in, started an xterm and started a screen inside. The cursor is blue, I am afraid. I am seeing this on all my three RH machines. If there is another config file I do not know about I am willing to learn.
Created attachment 124542 [details] .screenrc
Created attachment 124543 [details] .Xresources
Are you sure that the resources in your ~/.Xresources file are actually being merged in with xrdb ? They may not be, depending on which session / window manager you are using - gdm / kdm ? I really cannot reproduce this problem with a "*vt100*cursorColor:" setting known to be in the current x resources. Ensure that before running xterm you really have the resource set: $ xrdb -query | grep cursorColor XTerm.vt100.cursorColor: #xxxxxx $ xterm -e screen ( cursor really is colored #xxxxxx, even running screen with your .screenrc ! )
Yes, the values show up in xrdb. The cursor color is always correct (= matches the entry in .Xresources) when using a plain xterm. It is wrong when a screen is running in the xterm. I noticed something strange. This bug just shows if the cursor color (XTerm.vt100.cursorColor) and the foreground color (XTerm*foreground) are identical (which is the default, I suppose). When both values are different, the correct cursor color always shows, with or without a screen.
Aha! Yes, the issue was that xterm would not set the cursor color to xterm.vt100.cursorColor if that resource was the same as xterm*foreground - I have now reproduced this with xterm-208. There is now xterm-209.1 in Rawhide / FC5t3, which fixes this problem, as mentioned in /usr/share/doc/xterm-209/xterm.log.html : allow cursor to have the same color as foreground (text), since it is rendered as reverse (Debian #350664). Sorry for the confusion - I was testing with cursor color different to that of foreground. It was also impossible to reproduce with my default bash 'PS1' setting, which changed the foreground color of the prompt string and then back to a normal foreground color. So, please try xterm-209-1 from yesterday's Rawhide - it should fix this problem.
Oddly enough, that logic had been as-is for several years. But recently a few applications (such as vim) send escape sequences to change the cursor color.
Fixed as advertised.