Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Console doesn't correctly support Vim color themes #1706
I am trying to get vim to display 24-bit colour since I saw it was now supported on the latest insider build of windows - https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/
I cannot seem to get it working for some reason. This is my vimrc file:
And this is what vim looks like:
Also when I try and use
I get an error that NavyBlue is undefined but
Works, so vim only detects 16 colours.
Is there a solution for this or am I configuring it wrongly?
Thanks. Looks like you're still running an Ubuntu 14.04 instance; you may want to consider upgrading it to 16.04 or nuking it and re-creating, which will install 16.04, but you'll have to reinstall all your tools & settings afterwards.
Looks like you're running a fairly recent Vim build - same as the one I'm using, in fact.
Looks like you're experiencing the Vim background color erase issue described beautifully in this post: https://sunaku.github.io/vim-256color-bce.html
The solution to this issue is to set the following two lines to your
Take a look at my .vimrc that resulted in the following:
Thank you for your in depth reply. Could you please tell me how to upgrade the bash to 16.04?
I will try the suggested fix tomorrow as I'm in bed now but I set my term to screen-256color in my bashrc which improved it but there is still problems at the bottom of the terminal under the text, I will try and do this tomorrow and screenshot.
Regarding the solarized issues you are facing I think I fixed that with:
Above the colorscheme command in my vimrc.
@quiret thank you, my bad I usually search these things myself
@bitcrazed I have updated to 16.04 and added those things to my vimrc and I am still getting the problem of the colour not being applied below the text and to the side of the column in vim. I have used the solarized light colourscheme to highlight it here:
changed the title from
Cannot seem to get 24-bit colours working
Console doesn't correctly support color themes in Vim
Feb 17, 2017
@zadjii-msft Thanks for the update.
Please understand that getting Windows Subsystem for Linux working perfectly should be absolute top priority from Microsoft if you want developers to use Windows 10 instead of another certain competitor. As a developer, I had very high expectations on Creators Update in this perspective since the first release with WSL on Anniversary Update was with Ubuntu 14 and with very bad color support and overall didn't work well enough for professionals. Yes, such a seemingly "small thing" as bad color support, making it not nice to use Vim, is enough for a very large bunch of developers to look elsewhere.
I, and many many with me, don't care about anything else in the Creators Update but seeing that WSL is working perfectly for our developing needs. Unfortunately Microsoft still doesn't seem to be there. So I wonder; When this critical bug, discussed in this thread, is fixed, when and how will we developer get the update? Will we need to wait for the next major Windows 10 release after Creators Update? That is of course not an option so I really really hope that you can release it as an ordinary Windows Update and very soon as a hot fix.
@Microsoft: Please understand how important it is for your business to get WSL in perfect shape as soon as possible. We developers are driving trends. Look what happend with the Mac sales when developers started to use OSX. You really have your second chance here thanks to WSL but you need to put everything else aside and get WSL in top shape fast.
@snicke If you're a microsoft partner, tell this to your rep. I'm sure the team would be happy to have more resources dedicated to their project, but they aren't here to make business decisions like this.
Also, the console team and WSL team are different (the console team is only two people right now, miniksa and zadjii), so they really have to prioritize them as they come.
@fpqc well, there's actually a couple more of us... but it's exactly a couple more. We're the only ones who ever really contribute on GH.
I usually wouldn't reply to something like this, but hey, https://xkcd.com/303/
@snicke We have a lot of priorities at the moment. Most of them are down in the weeds priorities, getting real technical debt cleared up so that we can make more improvements in the future. We have some big long-term goals with the console, but it takes a lot of engineering effort to get there, and to get there without breaking any scenario that anyone has ever had.
In response to your specific callouts:
No @fpqc , I tell it to @Microsoft right here and right now even if it is in the middle of a bug ticket since it is, to my experience, impossible to reach out to them in Microsoft forums and I don't have the time or energy to look around. Please go ahead and tell your rep if you think that will take the project forward faster.
Great expectations? Yes! Unrealistic? No, IMHO.
Update: Thank you very much for a great answer @zadjii-msft. I really appreciate it (I don't understand though why you usually wouldn't reply as a Microsoft representative when a customer gives you feedback. I do answer my customers even if they aim high). Of course I realize that you have a lot of priorities as all projects do (ours too). I just wanted to be clear with what I, as a customer and a developer, desperately want to see in Windows and that I frankly thought would be the case already in AU according the information out there. Naive? No, I just read - from a pure Windows customer point of view - that native Ubuntu shell was going to be included in Windows AU (the best news from Microsoft since... ever) but without the energy too dig deep into it because of other professional priorities. Just frankly expected it to work like when firing up an Ubuntu shell and hence better IMHO than using an OSX terminal with its FreeBSD background. No, I'm unfortunately not here as a contributor. I just want to be able to use WSL efficiently as a developer and Microsoft paying customer in Windows 10 and I want to be able to use it now.
Feedback on why it probably is not an option for me, and many others, to wait another half a year to get WSL working in a good way on my company computers, where I cannot install any insider editions and also just need my tools to work so I can be productive from day 1: I already a year ago, maybe half a year before AU, seriously considered to do like so many other developers; skip Windows and switch to OSX because of its POSIX terminal and all nice things that comes with that for developers. Then I heard about WSL and that it would be included in Windows 10 AU and I was very excited and decided to wait. But I really don't think I can wait another half a year.
Don't get me wrong. I'm sure you're doing a great job with too limited resources and I'm also aware that I take a shortcut here and just want things to work from a customer point of view. But I'm just disappointed on Microsoft from that same customer point of view. Again.
With that said, if I can live with the Vim color shortcomings for now, do you consider WSL to be in good enough shape for daily professional developer use as an replacement for OSX terminal/pure Ubuntu terminal? I haven't played around that much but maybe just by chance I almost instantly got these annoying issues:
Then I started to get that "I give up" feeling since I already had given up on WSL in AU because of the coloring issues. But if the above issues can be fixed and there are not a lot more I might give it another try. And with a try I mean to use it as a OSX teminal/ubuntu terminal replacement for professional development.
@snicke If the bugs or unfinished stuff in the console is such a big deal, why don't you just use wsltty or build the wslbridge in msys2 or cygwin? (I even made a pkgbuild for msys2 and am trying to get it put into the upstream repos!)
I'm also looking forward to not having to use a third-party terminal emulator and just use the Windows console (if only because all the features and functionality will also find their way into things like powershell), but it's not polite to sit here barracking the developer to work faster on your particular bugbear. Right now, console problems (insofar as they don't relate to i/o redirection problems) are not really blocking anything in a way that can't be worked around by using the wslbridge.
There's already been significant technical payoff outside of the WSL project in the Win32-Openssh project because of the way they're doing things. So please be patient.