Console doesn't correctly support Vim color themes

[kabeersvohra]

Hi

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:

set nocompatible
filetype off

set rtp+=~/.vim/bundle/Vundle.vim
call pathogen#infect()
call vundle#begin()

Plugin 'VundleVim/Vundle.vim'
Plugin 'christoomey/vim-tmux-navigator'

call vundle#end()
filetype plugin indent on

colorscheme solarized
syntax enable
set background=dark
let g:solarized_termcolors=256
colorscheme solarized


set number
set tabstop=4
set shiftwidth=4
set softtabstop=4
set expandtab

And this is what vim looks like:
http://oi67.tinypic.com/2hs3yba.jpg

Also when I try and use

hi normal ctermfg=white ctermbg=navyblue

I get an error that NavyBlue is undefined but

hi normal ctermfg=white ctermbg=darkblue

Works, so vim only detects 16 colours.

Is there a solution for this or am I configuring it wrongly?

Thanks

Kabeer

[kabeersvohra]

Oh yeah I forgot to mention I am currently running insider build 15301

[kabeersvohra]

Also I have set my $term variable,

/bin/bash -c 'echo $TERM' returns xterm-256color

[zadjii-msft]

Have you tried set t_Co=256 in your .vimrc? IIRC solarized requires that. I remember @bitcrazed and I were having a discussion about this just about a month ago, maybe he remembers more.

[kabeersvohra]

@zadij-msft yeah I tried that as well, no success :/

[kabeersvohra]

I think this is a reproducible error if anyone from the dev team would be so kind as to test it and see what is wrong?

I hosted my config on git here:

https://github.com/KVohra95/config

many thanks

[bitcrazed]

@KVohra95 Could you also run the following and tell me what you get in return:

$ lsb_release -a
$ vim -version

Thanks.

[kabeersvohra]

kabeer@DESKTOP-5H2508C:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty
kabeer@DESKTOP-5H2508C:~$ vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:43:18)
Garbage after option argument: "-version"
More info with: "vim -h"
kabeer@DESKTOP-5H2508C:~$

[bitcrazed]

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 .vimrc:

set term=screen-256color
set t_ut=

Take a look at my .vimrc that resulted in the following:

Gruvbox (https://github.com/morhetz/gruvbox):

Monokai (https://github.com/sickill/vim-monokai):

Solarized (https://github.com/altercation/vim-colors-solarized):
Alas, the Solarized vim theme appears to cause issues - I'll explore this with @zadjii-msft for our next release.

[kabeersvohra]

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:

let g:solarized_termcolors=256

Above the colorscheme command in my vimrc.

[quiret]

Please see one of the following (closed) issues on the matter of upgrading to Xenial.

#1247
#941
#482

You can find worthwhile information by including closed issues into your search results :)

[kabeersvohra]

@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:

[fpqc]

@kvohra95 I think this is a console limitation atm. Workaround is set the background in the console settings for bash.exe.

[bitcrazed]

Yeah, that's likely something for @zadjii-msft to take a look at. I've filed a bug for us to triage & track (10996879)

[kabeersvohra]

ok cool, I tried to set the console colours by importing the solarized theme reg file as @fpqc recommended but that hasn't acheived the desired effect :/ thanks for putting it on the bug tracker

[AsukaLangleyfag]

i'm using https://github.com/mintty/wsltty since mintty have full color support. Also, simular project: https://github.com/goreliu/wsl-terminal (also uses mintty)

[kabeersvohra]

@AsukaLangleyfag thanks, this works actually but I much prefer the cmd based terminal over mintty so I will wait for the fix in the next version :)

[kabeersvohra]

@bitcrazed hi, has there been any progress on this issue? Thanks

[snicke]

I have the same problem as @KVohra95 and also wonder about the current status of the issue. Just installed Windows 10 Creators Update and the issue is still there.

[zadjii-msft]

@snicke Still a bug, still on the backlog, still MSFT:10996879. Hopefully I'll have enough time to get to it this release cycle.

[snicke]

@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.

[fpqc]

@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.

[zadjii-msft]

@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:

• Yes we knew that 256 color support was lacking in AU, that's why it was priority number 1 for CU. Priority 1 for AU was flushing out the VT engine enough that you could run basically any linux command-line app successfully, which hey, it did quite well. And now the color support is great, with only minor issues, like the bottom of vim not painting.
• I would not describe a partial coloring issue to be a "critical bug". Breaking remote.exe, echoing your password to the terminal after submitting, segfaulting when running tree - these are all critical bugs, and those would get serviced (had we not caught them)
• When I do get around to investigating this, it's gonna come as an update with the rest of the OS. Insiders will get it ~3wks after I complete a PR, and everyone else will get it when the next OS version ships. That's the Windows 10 OSaaS model. I would love to hear feedback from you why you feel that this isn't an option for you.

[fpqc]

@zadjii-msft I watched Rich on the Paul Thurrott show thing that he linked on Twitter, and he said there were only two of you 😒

[snicke]

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.

Instead:

• I expect Microsoft to already have taken the strategic business decisions to make WSL work perfectly on Windows and understand that this is their second chance to make developers go back to Windows.
• I further expect Microsoft managers, with the power to take the decisions to make this Microsoft's top priority, to read this and make it happen.
• I also expect individual Microsoft developers to escalate to decision makers/managers at Microsoft that they need more (or possibly a lot more) resources if they do and make them read this.

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:

• Vim coloring not working well enough
• Vim is really slow an choppy when just moving around in a buffer (holding down "j" and "k" using my usual .vimrc file) (something to do with the color issue?)
• Characters on the command line getting overwritten when editing characters on a command line (graphical bug) when SSH:ing into other machines.

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.

[fpqc]

@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.

[benhillis]

Locking this thread - please remain civil.

https://youtu.be/W5FfJ89rGPc?t=30

[zadjii-msft]

Hey, I wanted to let people know that the original issue filed here was just fixed. We weren't painting the color to the end of the line when someone emitted \x1b[K "Erase Line" with RGB colors.

This should be out to insiders sometime in the next few weeks.