Bug 178302 - Cursor color is wrong
Cursor color is wrong
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-19 04:23 EST by Ralf Ertzinger
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-30 13:29:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
.screenrc (163 bytes, text/plain)
2006-02-11 08:11 EST, Ralf Ertzinger
no flags Details
.Xresources (497 bytes, text/plain)
2006-02-11 08:12 EST, Ralf Ertzinger
no flags Details

  None (edit)
Description Ralf Ertzinger 2006-01-19 04:23:37 EST
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:
Comment 1 Jason Vas Dias 2006-01-19 16:25:15 EST
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.
Comment 2 Ralf Ertzinger 2006-01-20 04:20:52 EST
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
Comment 3 Thomas E. Dickey 2006-01-23 18:45:47 EST
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.
Comment 4 Jason Vas Dias 2006-02-10 16:19:01 EST
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.
Comment 5 Ralf Ertzinger 2006-02-11 08:11:03 EST
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.
Comment 6 Ralf Ertzinger 2006-02-11 08:11:53 EST
Created attachment 124542 [details]
.screenrc
Comment 7 Ralf Ertzinger 2006-02-11 08:12:29 EST
Created attachment 124543 [details]
.Xresources
Comment 8 Jason Vas Dias 2006-02-13 15:19:14 EST
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 ! )
Comment 9 Ralf Ertzinger 2006-02-14 14:00:44 EST
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.
Comment 10 Jason Vas Dias 2006-02-14 14:58:06 EST
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.
Comment 11 Thomas E. Dickey 2006-02-14 18:49:42 EST
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.
Comment 12 Ralf Ertzinger 2006-06-30 13:29:12 EDT
Fixed as advertised.

Note You need to log in before you can comment on or make changes to this bug.