Color rendering issues

[tycho]

Most colors don't render properly. Below examples use this script.

MinTTY (Cygwin):

Bash on Windows:

[zadjii-msft]

Right now conhost's color support is limited to the default 16 ASCII colors, but 256 color support is most definitely high on the backlog of things we'd like to support in the near future!

[jbaribeault]

Great to hear!

[kilobyte]

256 color support is an addition that is in no way required.

This said, because of a misdesign they do need to be explicitly recognized in order to be ignored, otherwise the result is interpreted as random unrelated codes (example: printf 'foo\e[38;5;1mbar\e[0m\n'). Here's how to detect them: https://github.com/torvalds/linux/commit/3415097ff0529eac264b8ccfa06572871e45c090 (my comment that 24-bit is "extremely rare" is no longer true: https://gist.github.com/XVilka/8346728).

Adding actual support for 256/24-bit color to conhost would require significant API changes -- Windows Console is internally married to the 16 color scheme. Just like Linux console (VT not some X terminal) -- the most you can do is to try match nearest color. I did happen to implement that: torvalds/linux@cec5b2a

Microsoft guys: I hereby relicense these two commits, please feel free to use/adapt them.

[bitcrazed]

Fixed internally. Bubbling up through the build system.

[retep998]

@bitcrazed Will there also be an equivalent Windows API method to take advantage of the enhanced color support?

[zadjii-msft]

@retep998 At this time, the API surface isn't changing at all. We're not yet supporting full 256 color or 24 bit RGB yet - we're merely finding the nearest color from the 16-color table and using that to render the color for applications using those sequences. Unfortunately, supporting true 256 color requires a lot more work than was possible to get done for this update.

[fredrikaverpil]

Fixed internally. Bubbling up through the build system.

Just curious... when is this supposed to bubble out to insider previews?

[zerocool4u2]

14352

[dreyks]

@zerocool4u2 how did you get those fancy powerline symbols working? Did you install additional fonts?

[zerocool4u2]

@dreyks yup i don't remember witch one was that, but there are some repos with patched fonts, https://github.com/gabrielelana/awesome-terminal-fonts https://github.com/ryanoasis/nerd-fonts/ are a couple of them, i'm actually currently working on courier prime code, that was my favorite and i'm trying to get a propper patch on it(most of them are patched with scrips and there aren't the best with most the scenarios, speceally with windows monospaced definition, if that makes sence), let me know if you want it, regards

[musm]

256 color support would be magical

[JoBrad]

Full color support would be amazing to have!

[laurensV]

Any estimation of when 256 color support will be available?

[bitcrazed]

No details just yet - will share once our planning settles-down.

[benhillis]

[cscorley]

I do not think this should be considered as "fixed" yet. Happy to have color mappings, but they're still mapping to incorrect colors. This is a workaround at best.

[kilobyte]

@cscorley: I'm afraid such a full fix would require so much work that WONTFIXing it for the time being is reasonable. The problem is, the CHAR_INFO structure has no room for expansion and gets passed to and from user programs a lot. Thus, a load of functions and structures would need to receive new versions and a translation layer between such a new internal format and the old API. Doesn't sound enticing to me to do that just to have more colors on the console.

Other SGR codes such as strikethrough, italic or blink have spotty support and about no use among Unix terminals, so 256/24-bit color would be the sole real gain.

[zadjii-msft]

This was closed as adding support for processing 256-color sequences, #345 is the current active issue for adding the actual full RGB color support

[cscorley]

All is very understandable w.r.t work needed for full color support. I was disappointed to find this marked fixed; thought that something was wrong with my environment for a long time. Missed the link to the new issue. Thanks, all!

[cscorley]

@SRGOM I've tried both ConEmu and ConsoleZ as of this week. They both do not add full 256 color support; both seem to display the same color mappings as above. Thanks for the suggestion, though.

[musm]

+1 to conemu, however it's kind of bloated and snapping doesn't work properly to due win32api bug apparently and does not have proper xterm compatible 256 colors using bash.

The solution I found for 256 colors is to use mintty! Install msys2 http://msys2.github.io/ and use that. It works for cmd and for bash you have 256 colors! They also have some awesome features planned like font fallbacks (which will be godsend for math programming in Julia due to all the unicode symbols Julia takes advantage of). In addition, it only works for powershell -version 2 there's a bug with the readline in powershell 3 in windows 10 that gives it problems when trying to run through mintty.

I'm still trying to figure out how to optimally configure mintty (key mappings are annoying)

[musm]

More pics:

[onomatopellan]

I agree so far the best way of using WSL with 256 colors is mintty, but better through this great package https://github.com/goreliu/wsl-terminal/releases

[musm]

wow what a great package, thank you @onomatopellan for linking!

[onomatopellan]

Totally safe. You can see in the source code those .exe are just AutoHotKey scripts. SmartScreen complains first time you run them because those executables are not signed.

[cscorley]

Thanks for all the suggestions in the thread. Unfortunately, none of these will work in my situation.

[deto]

Just found this out - relevant to this thread.

https://twitter.com/richturn_ms/status/779046431361343490

Apparently true-color support is coming in an insider build.