Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

True color support on Windows #23

Closed
Calinou opened this issue Jul 1, 2017 · 15 comments
Closed

True color support on Windows #23

Calinou opened this issue Jul 1, 2017 · 15 comments

Comments

@Calinou
Copy link

Calinou commented Jul 1, 2017

OS: Windows 10 Creators Update
Terminus version: Alpha 15

True color doesn't seem to work in Bash on Windows (regardless if connected to a SSH session or not), instead, all colors are approximated to the 16-color palette.
This was tested with micro with the MICRO_TRUECOLOR environment variable set to 1 (true color works in cmd.exe once this variable is set).

This issue can be reproduced by using the awk snippet available in the first link (the rainbow won't be smooth, but will be approximated to the 16-color palette instead).

Supporting true color will make using terminal applications (such as text editors with syntax highlighting) much more convenient.

@stale
Copy link

stale bot commented Aug 26, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks unless you comment.
Thank you for your contributions.

@stale stale bot added the S: Stale This issue had no activity for two months label Aug 26, 2018
@Calinou
Copy link
Author

Calinou commented Aug 30, 2018

The truecolor palette is still approximated (tested on Linux with Alpha 54 on the hterm and xterm front-ends).

@stale stale bot removed the S: Stale This issue had no activity for two months label Aug 30, 2018
@Eugeny
Copy link
Owner

Eugeny commented Sep 11, 2018

After some investigation, it looks like Windows' console host swallows the truecolor escape sequences before they can reach the terminal: microsoft/WSL#406

@codepuncher
Copy link

I've found that using a custom shell and pointing directly to C:\Windows\System32\wsl.exe has solved a lot of issues like this (I think it's using bash.exe instead which has different results).

@Eugeny
Copy link
Owner

Eugeny commented Sep 22, 2018

@codepuncher didn't work for me - how exactly did you test it?

@codepuncher
Copy link

@Eugeny apologies if this is a misunderstanding but when I use the default option in Terminus for WSL I just get incorrect characters and incorrect colour mappings. I'm using Zsh and when I use the custom shell option and point to wsl.exe everything renders correctly. Maybe the two executables have different ways of rendering?

@Eugeny
Copy link
Owner

Eugeny commented Oct 13, 2018

I'm not seeing any difference in rendering with wsl.exe vs bash.exe - at least with the awk script from https://gist.github.com/XVilka/8346728

@Eugeny
Copy link
Owner

Eugeny commented Dec 15, 2018

image

True Color now available with the xterm frontend - try the nightly build! https://ci.appveyor.com/project/Eugeny/terminus/build/artifacts

@MrKumaPants
Copy link

Sweet. Thank you so much!

@Tyriar
Copy link
Contributor

Tyriar commented Dec 17, 2018

@Eugeny how does this work? We don't support it yet 😕

@Eugeny
Copy link
Owner

Eugeny commented Dec 17, 2018

@Tyriar apparently you do? This is with your node-pty ConPTY integration branch, fresh xterm and WSL.

@Tyriar
Copy link
Contributor

Tyriar commented Dec 17, 2018

@Eugeny conpty will emit the colors in wsl, but xterm.js only allows storing and therefore rendering colors from the 256 color palette:

https://github.com/xtermjs/xterm.js/blob/4feed2dabc96ba78383af8d6adf43a9573459cf0/src/InputHandler.ts#L1635-L1639

That links shows each color takes up 9 bits for each color, 1 to flag whether it's the default, and 8 to encode 256 colors.

Are you sure that's not the hterm frontend which I think does support 24 bit color?

@Eugeny
Copy link
Owner

Eugeny commented Dec 17, 2018

Oh crap, you're right - I switched to hterm in my windows environment at some point and forgot about it. Any idea when the true color support is coming to xterm?

For reference: xtermjs/xterm.js#484

@Tyriar
Copy link
Contributor

Tyriar commented Dec 17, 2018

@Eugeny thought I was going crazy 😆

I did a prototype of true color a long time ago but chose to close it instead as it consumed too much memory due to the way the buffer is represented. @jerch has been working on a long project to improve the memory consumption and overall performance of the buffer which is nearing completion xtermjs/xterm.js#791, once this is done it will unblock features like true color and reflow.

Eugeny added a commit that referenced this issue Apr 29, 2019
@daaang
Copy link

daaang commented Jul 26, 2019

I'm unclear about how to enable 256 colors. I even tried upgrading to 1.0.88-nightly.0, and I'm still just seeing the usual 16 colors. If I run a VcXsrv X server and run terminator (not terminus) then I can run any of these print256colors scripts, and the output is all 256 colors. But in terminus (with any of the three frontends, running WSL / Bash on Windows), the same scripts try their best but are only able to approximate with the 16-color palate.

In both cases, $TERM is set to xterm-256color. Sorry to post in a long-closed ticket, but I'm liking this terminal emulator a lot so far, and it'd be really nice to have vim set up the way I'm used to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants