Description of problem: According to its man page, xterm is able to reverse the colors for background and foreground, when using the -r or -rv options However, none of these options work. xterm, with or without these options, uses the same color scheme. Version-Release number of selected component (if applicable): xterm-208-4.FC4 How reproducible: Always Steps to Reproduce: 1. run xterm with no parameters 2. make a not of the color scheme used by xterm 3. run xterm with either -r or -rv options 4. compare color scheme Actual results: xterm uses the same color scheme regardless of -r or -rv being used or not Expected results: With -r or -rv, xterm should flip the colors used for background and foreground Additional info:
Well, xterm DOES flip the fg & bg colors when no xterm*{fore,back}ground Xresources are set; the Xresource settings override the flipped default fg & bg. This does seem rather counterintuitive, so I applied a patch which will flip the fg & bg AFTER the xterm*{fore,back}ground resources take effect - fixed with xterm-213-1.FC4, being released to updates/testing today.
xterm-213-1.FC5 has been pushed for fc5, 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-213-1.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.
Actually it's not xterm that does the flipping, but Xt. And (looking at your patch) Xt doesn't flip the colors if they're done explicitly via the -fg or -bg options. Reading the bug report though, I'd thought we were only talking about "xterm -rv". The patch works for the case where we have "xterm -rv -fg red -bg blue", but not when colors are applied to the vt100 widget as in XTerm-col.ad's commented-out (and uncommented on my machine): ! Uncomment this for "white" text on a dark background. !*VT100*foreground: gray90 !*VT100*background: black
Revisiting this - I don't see the failure that I noted before. Will add that change (and look for reproducible issues ;-)