Summary: | konsole fails to draw bright colors in screen when TERM is set to xterm-256colors | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | Eckhart Wörner <ewoerner> |
Component: | general | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | adaptee, chaos.proton, kde, ormaaj |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: |
Description
Eckhart Wörner
2010-04-02 13:46:37 UTC
I was able to reproduce this problem by following the spurious advice given in that first link: http://www.frexx.de/xterm-256-notes/ ----- By default, screen is not aware that it is running in a 256 color capable xterm. To make programs in screen recognize this feature, you need to set three things in your ~/.screenrc: # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b ".I" # tell screen how to set colors. AB = background, AF=foreground termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' # erase background with current bg color defbce "on" ----- From what I can tell, none of that has anything to do with 256 color support. The culprit seems to be the attrcolor b ".I" line. According to the screen docs, this means approximately "modify characters marked as bold to have a high-intensity background of the current color." The screen manual may be partially at fault because it gives this same example described as: "Use bright colors for bold text. Most terminal emulators do this already.", while in the previous paragraph the capital "I" is described as a pseudo-attribute which alters the background rather than foreground color. Both resetting the color with "attrcolor b", or using the correct attribute of 'attrcolor b ".i"' makes things show up correctly. I don't have xterm installed but urxvt seems to ignore the attrcolor setting, and if xterm does the same that would explain why the reporter only noticed this in Konsole. Interestingly, my Konsole behaves reverse of what's reported. If TERM=xterm in the Bash environment screen is run from, then bold colors are not intense regardless of attrcolor setting. If TERM=xterm-256color then they show as intense just as they would outside of screen.This may yet be a valid bug as I'm unsure why setting the background color to intense for bold text would negate the intense foreground color. See: http://www.gnu.org/software/screen/manual/screen.html#Attrcolor http://www.gnu.org/software/screen/manual/screen.html#String-Escapes Though I think the bug being discussed is unrelated, this recent mailing list post helped clear things up too: http://lists.kde.org/?l=konsole-devel&m=127811329005415&w=2 *** Bug 194056 has been marked as a duplicate of this bug. *** Well, by combining the steps mentioned in the original report and the condition mentioned in comment #1, I can kind of reproduce this problem with konsole-2.7.2. But I can't reproduce it with konsole-2.7.999. I think this problem share the same cause with bug #274603, which is already fixed recently. *** This bug has been marked as a duplicate of bug 274603 *** I can reproduce this bug in konsole 2.8.3 (KDE 4.8.3) when connecting to my FreeBSD (9.0-RELEASE) server. It does NOT happen when connecting to my Gentoo box. The yellow/orange swap (bug 274603) does NOT happen in this case, quite the opposite: inside screen/tmux, both "BOLD" words show in their respective colors, while the both show up as yellow outside screen/tmux (as they do on the Linux box). None of this happens when using urxvt or putty. |