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

Console doesn't correctly support Vim color themes #1706

Closed
kabeersvohra opened this Issue Feb 15, 2017 · 27 comments

Comments

Projects
None yet
10 participants
@kabeersvohra

kabeersvohra commented Feb 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 15, 2017

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

kabeersvohra commented Feb 15, 2017

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

@kabeersvohra

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 15, 2017

Also I have set my $term variable,

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

kabeersvohra commented Feb 15, 2017

Also I have set my $term variable,

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

@benhillis benhillis added the console label Feb 16, 2017

@zadjii-msft

This comment has been minimized.

Show comment
Hide comment
@zadjii-msft

zadjii-msft Feb 16, 2017

Member

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.

Member

zadjii-msft commented Feb 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 16, 2017

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

kabeersvohra commented Feb 16, 2017

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

@kabeersvohra

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 16, 2017

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

kabeersvohra commented Feb 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bitcrazed

bitcrazed Feb 17, 2017

Collaborator

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

$ lsb_release -a
$ vim -version

Thanks.

Collaborator

bitcrazed commented Feb 17, 2017

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

$ lsb_release -a
$ vim -version

Thanks.

@kabeersvohra

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 17, 2017

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:~$

kabeersvohra commented Feb 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bitcrazed

bitcrazed Feb 17, 2017

Collaborator

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):
2017-02-16 gruvbox

Monokai (https://github.com/sickill/vim-monokai):
2017-02-16 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.
2017-02-16 solarized

Collaborator

bitcrazed commented Feb 17, 2017

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):
2017-02-16 gruvbox

Monokai (https://github.com/sickill/vim-monokai):
2017-02-16 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.
2017-02-16 solarized

@kabeersvohra

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 17, 2017

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.

kabeersvohra commented Feb 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@quiret

quiret Feb 17, 2017

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

quiret commented Feb 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 17, 2017

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

capture

kabeersvohra commented Feb 17, 2017

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

capture

@fpqc

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Feb 17, 2017

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

fpqc commented Feb 17, 2017

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

@bitcrazed bitcrazed changed the title from Cannot seem to get 24-bit colours working to Console doesn't correctly support color themes in Vim Feb 17, 2017

@bitcrazed bitcrazed changed the title from Console doesn't correctly support color themes in Vim to Console doesn't correctly support Vim color themes Feb 17, 2017

@bitcrazed

This comment has been minimized.

Show comment
Hide comment
@bitcrazed

bitcrazed Feb 17, 2017

Collaborator

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

Collaborator

bitcrazed commented Feb 17, 2017

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

@bitcrazed bitcrazed added the bug label Feb 17, 2017

@kabeersvohra

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 17, 2017

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

kabeersvohra commented Feb 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@AsukaLangleyfag

AsukaLangleyfag Feb 20, 2017

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)

AsukaLangleyfag commented Feb 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Feb 20, 2017

@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 commented Feb 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kabeersvohra

kabeersvohra Apr 6, 2017

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

kabeersvohra commented Apr 6, 2017

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

@jackchammons jackchammons removed the bug label Apr 11, 2017

@snicke

This comment has been minimized.

Show comment
Hide comment
@snicke

snicke Apr 22, 2017

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.

snicke commented Apr 22, 2017

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 zadjii-msft added the bug label Apr 24, 2017

@zadjii-msft

This comment has been minimized.

Show comment
Hide comment
@zadjii-msft

zadjii-msft Apr 24, 2017

Member

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

Member

zadjii-msft commented Apr 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@snicke

snicke Apr 27, 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 commented Apr 27, 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.

@fpqc

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Apr 27, 2017

@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 commented Apr 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@zadjii-msft

zadjii-msft Apr 27, 2017

Member

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

zadjii-msft commented Apr 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Apr 27, 2017

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

fpqc commented Apr 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@snicke

snicke Apr 27, 2017

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.

snicke commented Apr 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@fpqc

fpqc Apr 28, 2017

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

fpqc commented Apr 28, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@benhillis

benhillis Apr 28, 2017

Member

Locking this thread - please remain civil.

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

Member

benhillis commented Apr 28, 2017

Locking this thread - please remain civil.

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

@Microsoft Microsoft locked and limited conversation to collaborators Apr 28, 2017

@zadjii-msft

This comment has been minimized.

Show comment
Hide comment
@zadjii-msft

zadjii-msft Jun 14, 2017

Member

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.

Member

zadjii-msft commented Jun 14, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.