"bold colours" and xterm-256color

[Frank Terbeck]

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

[Nicholas Marriott]

Hi

Are you expecting a bold font as well?

It works fine for me with putty, I'll try xterm when I get home.

There are various implementations of bold in 256 colour mode,

https://sourceforge.net/tracker/?func=detail&aid=2810418&group_id=200378&atid=973265

may be related.

Post by Frank Terbeck
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.
[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.
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
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/tmux-users

[Frank Terbeck]

Post by Nicholas Marriott
Are you expecting a bold font as well?

Well, no. I'm using the following resources, that should turn off bold
characters everywhere in xterm:

[snip]
XTerm*font: -*-terminus-*-*-*-*-12-*-*-*-*-*-*-*
XTerm*boldFont: -*-terminus-*-*-*-*-12-*-*-*-*-*-*-*
XTerm*boldMode: false
XTerm*boldColors: true
XTerm*colorBDMode: true
[snap]

Post by Nicholas Marriott
It works fine for me with putty, I'll try xterm when I get home.
There are various implementations of bold in 256 colour mode,
https://sourceforge.net/tracker/?func=detail&aid=2810418&group_id=200378&atid=973265
may be related.

Yeah, that sounds similar to what I'm seeing.

Btw, 256colors.pl does show light blue in "System colors". But it uses
"\e[38;5;12m" instead of "\e[01;34". I think the former directly uses
foreground colour number 12.

I created a few screenshots, to show you what I'm seeing:

Xterm, without any terminal multiplexer running:
<Loading Image...>

The same Xterm, with tmux:
<Loading Image...>

And the same Xterm, with screen running:
<Loading Image...>

This is happening on debian linux (stable) using this xterm:

% xterm -version
XTerm(235)

Regards, Frank

[Nicholas Marriott]

Hi

There are differences in how setaf is defined between xterm and xterm-256color:

$ TERM=xterm tput setaf 4|cat -v; echo
^[[34m
$ TERM=xterm-256color tput setaf 4|cat -v; echo
^[[38;5;4m

So, when you do:

$ printf '\e[1;34mabc'

tmux sets colour 4 using setaf which with xterm-256color ends up as:

^[[1m^[[38;5;4mabc

This means you get bold + colour 4. In the 256 colour palette, 4 is hardcoded
to ANSI blue. You've told xterm not to use a bold font, so it doesn't change
that, and there are no bold colours in the 256 colour palette, so you just get
colour 4, normal ANSI blue.

I think what you want can be produced by making tmux use the standard escape
sequence for normal colours and only use the extended sequence (\e[38;5;n) for
the 256 colour palette. You can do this either by just using TERM=xterm and
starting the tmux server with -2 to force it to use 256 colours, or by
overriding setaf and setab, something like:

set -ag terminal-overrides ",xterm-256color:setaf=\e[3%p1%dm:setab=\E[4%p1%dm"

Post by Frank Terbeck

Post by Nicholas Marriott
Are you expecting a bold font as well?

Well, no. I'm using the following resources, that should turn off bold
[snip]
XTerm*font: -*-terminus-*-*-*-*-12-*-*-*-*-*-*-*
XTerm*boldFont: -*-terminus-*-*-*-*-12-*-*-*-*-*-*-*
XTerm*boldMode: false
XTerm*boldColors: true
XTerm*colorBDMode: true
[snap]

Post by Nicholas Marriott
It works fine for me with putty, I'll try xterm when I get home.
There are various implementations of bold in 256 colour mode,
https://sourceforge.net/tracker/?func=detail&aid=2810418&group_id=200378&atid=973265
may be related.

Yeah, that sounds similar to what I'm seeing.
Btw, 256colors.pl does show light blue in "System colors". But it uses
"\e[38;5;12m" instead of "\e[01;34". I think the former directly uses
foreground colour number 12.
<http://ft.bewatermyfriend.org/tmp/256without.png>
<http://ft.bewatermyfriend.org/tmp/256tmux.png>
<http://ft.bewatermyfriend.org/tmp/256screen.png>
% xterm -version
XTerm(235)
Regards, Frank

[Frank Terbeck]

Post by Nicholas Marriott
$ TERM=xterm tput setaf 4|cat -v; echo
^[[34m
$ TERM=xterm-256color tput setaf 4|cat -v; echo
^[[38;5;4m
$ printf '\e[1;34mabc'
^[[1m^[[38;5;4mabc
This means you get bold + colour 4. In the 256 colour palette, 4 is hardcoded
to ANSI blue. You've told xterm not to use a bold font, so it doesn't change
that, and there are no bold colours in the 256 colour palette, so you just get
colour 4, normal ANSI blue.
I think what you want can be produced by making tmux use the standard escape
sequence for normal colours and only use the extended sequence (\e[38;5;n) for
the 256 colour palette. You can do this either by just using TERM=xterm and
starting the tmux server with -2 to force it to use 256 colours, or by

This seems to work...

Post by Nicholas Marriott
set -ag terminal-overrides ",xterm-256color:setaf=\e[3%p1%dm:setab=\E[4%p1%dm"

...while this one sadly doesn't. It actually completely breaks my
output:

zsh% printf '\e[38;5;12mfoo\n'
foo <- That foo is actually in light blue, but:

zsh% printf '\e[01;34mfoo\n'
E[34mfoo
zsh%

Since I'm no expert in this terminfo business, that leaves me a little
puzzled; especially, since I would prefer the $terminal-overrides
solution.

Regards, Frank

[Nicholas Marriott]

Maybe I got the terminal-overrides string wrong, can you run tmux server-info
after starting tmux with it set and tell me what setaf and setab are set to?

Post by Frank Terbeck

Post by Nicholas Marriott
$ TERM=xterm tput setaf 4|cat -v; echo
^[[34m
$ TERM=xterm-256color tput setaf 4|cat -v; echo
^[[38;5;4m
$ printf '\e[1;34mabc'
^[[1m^[[38;5;4mabc
This means you get bold + colour 4. In the 256 colour palette, 4 is hardcoded
to ANSI blue. You've told xterm not to use a bold font, so it doesn't change
that, and there are no bold colours in the 256 colour palette, so you just get
colour 4, normal ANSI blue.
I think what you want can be produced by making tmux use the standard escape
sequence for normal colours and only use the extended sequence (\e[38;5;n) for
the 256 colour palette. You can do this either by just using TERM=xterm and
starting the tmux server with -2 to force it to use 256 colours, or by

This seems to work...

Post by Nicholas Marriott
set -ag terminal-overrides ",xterm-256color:setaf=\e[3%p1%dm:setab=\E[4%p1%dm"

...while this one sadly doesn't. It actually completely breaks my
zsh% printf '\e[38;5;12mfoo\n'
zsh% printf '\e[01;34mfoo\n'
E[34mfoo
zsh%
Since I'm no expert in this terminfo business, that leaves me a little
puzzled; especially, since I would prefer the $terminal-overrides
solution.
Regards, Frank

[Frank Terbeck]

Post by Nicholas Marriott
Maybe I got the terminal-overrides string wrong, can you run tmux server-info
after starting tmux with it set and tell me what setaf and setab are set to?

This is what I get:
68: setab: (string) E[4%p1%dm
69: setaf: (string) E[3%p1%dm

Regards, Frank

[Frank Terbeck]

Did you use \e or \E in terminal-overrides? tmux expects \e but terminfo uses
\E which won't work in tmux.

Heh, well. I indeed used \E, as you used both in your example line
earlier and infocmp's output used \E, too. So, I tried both as \E when
mixing \E and \e had failed... :-)

When using \e exclusively, it does work as you expected. Quite nice.
Thanks!

Regards, Frank

[Nicholas Marriott]

Hmm okay, I managed to use \e for one entry and \E for the other... :-/ time to
cut down on the beer I guess ;-).

Post by Frank Terbeck

Did you use \e or \E in terminal-overrides? tmux expects \e but terminfo uses
\E which won't work in tmux.

Heh, well. I indeed used \E, as you used both in your example line
earlier and infocmp's output used \E, too. So, I tried both as \E when
mixing \E and \e had failed... :-)
When using \e exclusively, it does work as you expected. Quite nice.
Thanks!
Regards, Frank

[Chris Jones]

Post by Frank Terbeck
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.
[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

[Frank Terbeck]

[...]

Post by Chris Jones

Post by Frank Terbeck
With one exception. Colours with bold attribute appear as if the bold
attribute wasn't there.

[...]

Post by Chris Jones
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.

I think I even read parts of a thread about this when I was trying to
figure out how to tackle this problem. :-)

[...]

Post by Chris Jones
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.

What would those setaf= and setab= values be?

Post by Chris Jones
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..!

That is kind of weird, because my debian lenny tells me, its curses
version is: 5.7+20081213-1 - which is well beyond 2006.

[...]

Post by Chris Jones
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..?

If it is indeed a debian problem, that certainly would be the right
way to go.

Regards, Frank

[Chris Jones]

[...]

Post by Frank Terbeck
What would those setaf= and setab= values be?

Attaching the infocmp of the version in the ncurses tarball.

Post by Frank Terbeck

Post by Chris Jones
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..!

That is kind of weird, because my debian lenny tells me, its curses
version is: 5.7+20081213-1 - which is well beyond 2006.

Nothing in the ncurses tarball that looks like the above versioning

Perhaps corresponds to the debian build date?

Post by Frank Terbeck
[...]
If it is indeed a debian problem, that certainly would be the right
way to go.

The merit of fixing it via an updated terminfo entry is that you don't
have to rely on an application's providing an escape hatch that lets you
modify the description of the terminal. Heck, the cvs version of tmux
that I built a couple of months ago didn't yet have this capability.

CJ

[Frank Terbeck]

Post by Chris Jones

Post by Frank Terbeck
What would those setaf= and setab= values be?

Attaching the infocmp of the version in the ncurses tarball.

Either I'm blind or you forgot to attach or the tmux-users list strips
attachments. :-)

Regards, Frank