Terminal: Wrong colors in airline text when in tmux but ok in wsltty

[persep]

• Your Windows build number: Microsoft Windows [Version 10.0.16299.309]

• What you're doing and what's happening: see description below

• What's wrong / what should be happening instead: see description below

Hi,
when in terminal (ubuntu on windows) and in wsltty (mintty 2.8.4 wsltty 1.8.4) I have vim with gruvbox and the gruvbox airline all working ok:

If I change to the wombat airline theme, for testing purposes, it also works ok:

So the airline themes work fine in the terminal but if I open vim inside tmux on ubuntu for windows I get a different color in the text from the vim status line but it's the correct colors in tmux on wsltty. Look at the different color in the "NORMAL" text

And if a change to the wombat airline you can see the "NORMAL" text color is also lighter:

It happens to all the other airline themes like solarized for example.
I've tried this in vim 8-1605 and tmux 2.1 and 2.6. I've also tried with tmux in 256 and 24 bit colors and it doesn't make a difference. Vim colors schemes are ok in tmux but not the text color from the airline themes. They render with wrong colors inside tmux on the ubuntu on windows terminal but correctly in tmux on wsltty.

My .tmux.conf file is:

set -g default-terminal "tmux-256color"                                              
# enable 24 bit support                                                              
set -g terminal-overrides ',xterm-256color:Tc'

And my vimrc is here

[mkarpoff]

I've noticed this as well.

[zadjii-msft]

I'll add it to my bug backlog. It might have been fixed for the upcoming release, but I doubt it. Looks like vim is doing something to change the attributes, and then tmux is emitting something like "use defaults", but we're not properly undoing whatever vim did.

[slabua]

I'm quite positive the issue is related to how the bold attribute is handled.
Should it be posted somewhere here too, perhaps? https://github.com/Microsoft/wsl/issues

[persep]

Yes it looks like a bug with the bold rendering

In wsltty outside tmux:

In bash ubuntu on windows outside tmux:

[WSLUser]

No console issues regarding WSL should be in WSL per WSL Contributing.md

[zadjii-msft]

@persep god bless your soul for a repro that doesn't involve invoking vim and tmux. That's a string I can write a unit test against :)

[persep]

@zadjii-msft Don't tell me about it. I opened a bug report in gruvbox, vim-airline, and tmux before I got to the console :-) . It was @nicm from tmux that had the idea, credit where credit's due.

Just so you can copy the string:
printf '\033[38;2;40;40;40m\033[48;2;168;153;132m\033[1m NORMAL \033[m'

[ehuss]

From my experiments, it appears issuing the bold sequence after any of the extended color sequences will override the foreground color.

\033[33m\033[1mBold Yellow\033[m
\033[38;2;255;0;0m\033[1mBold Red\033[m
\033[38;5;46m\033[1mBold Green\033[m

But if you issue the bold sequence first, then it doesn't override the foreground color.

\033[1m\033[38;2;255;0;0mBold Red\033[m
\033[1m\033[38;5;46mBold Green\033[m

[j4james]

The bold/brightness attribute was designed to work with the basic color system that had a palette of only 8 colors with dim and bright counterparts. When you're dealing with the 256-color palette or 24-bit colors there obviously isn't a similar bright version of each color, so what happens is you get the bright version of the last selected color from the 8-color palette.

As an example:

printf "\033[31m Basic Red \033[38;2;0;255;0m 24-bit Green \033[1m Bright Red, Not Green \033[m"

There's never going to be a perfect solution to this problem, but what some terminal emulators do is try and find the closest match in the 8-color palette whenever you select a 24-bit color or one of the 256-color palette values. That color then becomes the base value used when the bold attribute is applied (or turned off).

[nicm]

I don't know what terminal you are specifically talking about but this is a not a useful way to implement attributes.

Making SGR 1 (or any other attribute) change the foreground colour as well as the attribute is a mistake and not what applications will expect. If I send your example, I expect the last text to be green, not red, whether or not the terminal supports combining bright with RGB colours.

If the terminal does not support combining bright with a colour from the 256 palette or an RGB colour, the least surprising thing to do is to render the colour without the bright attribute at all, but remember the attribute if the foreground colour is changed to a colour where it is supported.

[RobertDurfee]

A quick workaround is to just tell airline not to bold those elements. Just add the following to your .vimrc:

call airline#parts#define_accent('mode', 'none')
call airline#parts#define_accent('linenr', 'none')
call airline#parts#define_accent('maxlinenr', 'none')

Not a solution, but it makes airline a little more usable in tmux in wsl.

[zadjii-msft]

Before and after:

Heading to code review :)

[persep]

Looks good

[zadjii-msft]

Fix is in the October 2018 update.