On Thu, Sep 24, 2009 at 09:48:02AM EDT, Frank Terbeck wrote: > Hey list!
> I've been playing around with a 256 colour xterm and tmux. I've been > following the FAQ entry and that worked. > > With one exception. Colours with bold attribute appear as if the bold > attribute wasn't there. > I used this to test: > [snip] > printf '\e[01;34mfoo\n' > printf '\e[34mfoo\n' > [snap] > The former should print a 'foo' in light blue, the latter a 'foo' in > normal blue. This *works* in xterm itself, but fails if I start tmux > in the same terminal. > > GNU screen behaves like tmux, but if I do this in screen: attrcolor b > "I" ...it behaves like I'd expect. > > TERM in xterm is 'xterm-256color' (it doesn't matter if I use 'screen' > or 'screen-256color' inside tmux to reproduce). > > If TERM is 'xterm', "bold colours" work in tmux. > > Is there a way to do what screen's 'attrcolor' does? Or am I missing > something obvious? > > Regards, Frank As an aside... I first ran into this annoying issue while still on debian "etch" when I first noticed that "bright" colors were not rendered correctly in one particular ncurses application, namely the (excellent) weechat-curses irc client - neither under GNU/screen or running native on xterm, with $TERM=xterm-25color. When I spotted this thread, I ran the same tests on a 256-color xterm, now on debian "lenny", and although the above printf's did display the correct colors, neither weechat nor the barebones ncurses test snippets that I wrote at the time displayed colors 9-15 correctly. I proceeded to run the same test under pterm (putty) and found that not only were these colors displayed correctly when running weechat and my test code snippets, but that both tmux without any relevant config options as well as GNU/screen with the attrcolor b "I" commented out ran fine in this respect. Pretty much on a hunch, I hacked a ~/.terminfo entry for 256-color xterm that changed the setaf= and setab= values to those that are specified in putty-256color, tested again with $TERM set to this custom terminfo entry, and sure enough, everything I threw at it worked fine, at least with regards to "bold" colors. At that point I figured it was time to get in touch with Thomas Dickey, the upstream xterm and ncurses maintainer, who informed me that the current xterm-256color entry has precisely the setaf= and setab= values of my hacked version and that this has been the case since 2006..! I was thinking of blaming the "stability" of debian "stable" - until I found that supposedly cutting-edge ubuntu 9.04 also still sports the same setaf= and setab= values... ;-) I compiled the current version of ncurses and ran further tests with the updated xterm-256color terminfo entry and in every context I tested, everything appears to work as intended: all 0-256 colors are correctly rendered. So maybe the long-term solution to this issue is to bug the debian maintainers until they provide the user community with a long-awaited update of the ncurses package..? :-) CJ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
