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

xterm-256/24-bit colors are not supported #9

Closed
nta opened this issue Feb 16, 2018 · 13 comments
Closed

xterm-256/24-bit colors are not supported #9

nta opened this issue Feb 16, 2018 · 13 comments
Labels
upstream This due to an external component we are using

Comments

@nta
Copy link

nta commented Feb 16, 2018

The terminal does not seem able to display extended (256-color/24-bit) terminal color sequences, instead displaying a lot of escape codes.

@felixse
Copy link
Owner

felixse commented Feb 16, 2018

Hi,
can you tell me which shell you experience this with?

@felixse
Copy link
Owner

felixse commented Feb 17, 2018

So apparently the problem is that winpty does not support 256 colors: rprichard/winpty#108
Don't see any chance to fix this in the foreseeable future 😕

@felixse felixse added enhancement New feature or request help wanted Extra attention is needed labels Feb 17, 2018
@felixse felixse removed the help wanted Extra attention is needed label May 23, 2018
@felixse felixse added upstream This due to an external component we are using and removed enhancement New feature or request labels May 31, 2018
@hanskokx
Copy link
Contributor

Is this why my vim colors don't show up properly?
capture

@felixse
Copy link
Owner

felixse commented May 31, 2018

Yes, exactly.
Microsoft is currently working on an official alternative for winpty (microsoft/terminal#57) that might support this, but I have no idea when this will be released

@Riebart
Copy link
Contributor

Riebart commented Aug 18, 2018

Quick update: microsoft/terminal#57 is officially closed, that TTY API is coming in the fall release of Windows 10.

@felixse
Copy link
Owner

felixse commented Aug 18, 2018

Yes, i read the blog post, this will be good. I plan to implement it once it hits the release preview update ring.

@Jaykul
Copy link

Jaykul commented Mar 28, 2019

@felixse is this closed because it's fixed now? Because I downloaded 0.4.1 yesterday, and was just about to file this as a bug 😉 (thanks to node-pty 0.8 VS Code fixed this awhile ago, and Hyper got this fixed in their canary builds, so I was expecting to see it would work here too ...

@Riebart
Copy link
Contributor

Riebart commented Mar 29, 2019

This works on Windows 10 1809 when not using winpty as the console backend. So give that a whirl and see if it is still an issue.

@Jaykul
Copy link

Jaykul commented Mar 29, 2019

That's weird. I'm happy to open a new issue to discuss this, but isn't WinPTY meant to be the new hotness? How is it working without that, but not with!?

@Riebart
Copy link
Contributor

Riebart commented Mar 30, 2019

ConPTY is the new wrapper provided by the Windows kernel starting in 1809. WinPTY was the previous third party wrapper, and while may grow to support ConPTY, for our needs using ConPTY is supported directly by FluentTerminal.

@Jaykul
Copy link

Jaykul commented Mar 30, 2019

Seems like that checkbox should be off by default, then.

@Riebart
Copy link
Contributor

Riebart commented Mar 30, 2019

My understanding is that ConPTY support is still experimental in FluentTerminal, hence why it isn't the default.

@horseinthesky
Copy link

I really don't know what WinPTY and ConPTY are. What is the reason of my nvim in SecureCRT looks like this
Screenshot_1

And nvim in FluentTerminal like this?
Screenshot_2

Can it be fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream This due to an external component we are using
Projects
None yet
Development

No branches or pull requests

6 participants