ColorTool: Background color not working correctly #19

@Nacimota commented on GitHub (Aug 27, 2017):

So up until very recently the console only supported 16 colours at a time. When the PowerShell team decided they wanted a very specific dark blue as the background colour, rather than altering the colour value for dark or light blue, they instead changed dark magenta to blue and used that as the background colour. I'm not precisely sure why they did this, there's probably some reasoning floating around on the internet somewhere. As a side note, they also changed dark yellow to a light grey and used that as the default foreground for some reason; again, I'm not really sure why.

The end result is that colortool is changing the colours correctly, the problem is simply that PowerShell gets its background colour from a different slot in the colour table.

You can of course fix this yourself by setting the screen background manually in the properties window. As for fixing it in colortool, I'm not sure how or if we should do that. It might be as simple as checking if the parent process is powershell, and if so, setting these registry values to 0x07 (or something similar):

Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe\ScreenColors
Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_SysWOW64_WindowsPowerShell_v1.0_powershell.exe\ScreenColors

But that doesn't take effect until the window is reopened; I'm not sure how to change the screen background for the currently open window.

@Nacimota commented on GitHub (Aug 27, 2017): So up until very recently the console only supported 16 colours at a time. When the PowerShell team decided they wanted a very specific dark blue as the background colour, rather than altering the colour value for dark or light blue, they instead changed dark magenta to blue and used that as the background colour. I'm not precisely sure why they did this, there's probably some reasoning floating around on the internet somewhere. As a side note, they also changed dark yellow to a light grey and used that as the default foreground for some reason; again, I'm not really sure why. The end result is that colortool is changing the colours correctly, the problem is simply that PowerShell gets its background colour from a different slot in the colour table. ![cmd and powershell colours](https://i.imgur.com/Z4bLKVm.png) You can of course fix this yourself by setting the screen background manually in the properties window. As for fixing it in colortool, I'm not sure how or if we should do that. It might be as simple as checking if the parent process is powershell, and if so, setting these registry values to `0x07` (or something similar): Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe\ScreenColors Computer\HKEY_CURRENT_USER\Console\%SystemRoot%_SysWOW64_WindowsPowerShell_v1.0_powershell.exe\ScreenColors But that doesn't take effect until the window is reopened; I'm not sure how to change the screen background for the currently open window.

claunia commented

@wavebeem commented on GitHub (Aug 27, 2017):

🤔 Very interesting. Thanks for the detailed response.

@wavebeem commented on GitHub (Aug 27, 2017): 🤔 Very interesting. Thanks for the detailed response.

claunia commented

@parkovski commented on GitHub (Oct 20, 2017):

Looking at an itermcolors file, this is not quite possible with the current conhost. There are colors 0-15 listed, but there are also separate foreground and background colors, which are not selected from the standard palette. There are others (cursor, cursor text, selection, selected text, and bold) - it'd be nice to have support for setting all of these separately, but top priority for me would be foreground and background. We won't have true itermcolors support until conhost can set those colors independently from the standard 16-color palette.

Compare the screenshot to the ones shown here. In the screenshot in this thread, either the 40m column or the 45m matches the background. That is not the case in any of the screenshots for the link I provided.

The reason I think this should be a priority - when the theme's background color doesn't match the intended one, some text can be really difficult to read.

@parkovski commented on GitHub (Oct 20, 2017): Looking at an `itermcolors` file, this is not quite possible with the current conhost. There are colors 0-15 listed, but there are also separate foreground and background colors, which are _not_ selected from the standard palette. There are others (cursor, cursor text, selection, selected text, and bold) - it'd be nice to have support for setting all of these separately, but top priority for me would be foreground and background. We won't have true `itermcolors` support until conhost can set those colors independently from the standard 16-color palette. Compare the screenshot to the ones shown [here](https://github.com/mbadolato/iTerm2-Color-Schemes#screenshots). In the screenshot in this thread, either the `40m` column or the `45m` matches the background. That is not the case in any of the screenshots for the link I provided. The reason I think this should be a priority - when the theme's background color doesn't match the intended one, some text can be really difficult to read.

claunia commented

@flstaats commented on GitHub (Nov 5, 2017):

The fix is simple and I would love to see the colortool do it automatically.

Open a PowerShell windows using the shortcut or command you would normally used.
Use the colortool.exe to set the colors (with the -c, -b or -d options as appropriate)
In the command window border open right click menu Properties for this instance (or Defaults for the settings for new windows not already associated with a shortcut.)
In the colors tab select "Screen Text" and associate with the right most color box (white)
In the colors tab select "Screen Background" and associate with the left most color box (black)
In the colors tab select "Popup Text" Select the popup text color you want... I choose the default gold
In the colors tab select "Popup Background" select the right most color box (white) and save

The default Text and Background colors could and should be selected by the colortool as they are just another registry setting being set. It would be reasonable to optionally not set them with another flag but in most cases where people are using colortool they don't want a bright pink/purple background in their PowerShell windows!!!

Just because the out of the PowerShell selects a non-default color for the background (I've never understood the hard to read choice of dark blue), doesn't mean that the colortool can't be more sensible. I consider the current behavior of making one of the two built in shell programs unreadable to be a major bug.

@flstaats commented on GitHub (Nov 5, 2017): The fix is simple and I would love to see the colortool do it automatically. 1. Open a PowerShell windows using the shortcut or command you would normally used. 2. Use the colortool.exe to set the colors (with the -c, -b or -d options as appropriate) 3. In the command window border open right click menu Properties for this instance (or Defaults for the settings for new windows not already associated with a shortcut.) 4. In the colors tab select "Screen Text" and associate with the right most color box (white) 5. In the colors tab select "Screen Background" and associate with the left most color box (black) 6. In the colors tab select "Popup Text" Select the popup text color you want... I choose the default gold 7. In the colors tab select "Popup Background" select the right most color box (white) and save The default Text and Background colors could and should be selected by the colortool as they are just another registry setting being set. It would be reasonable to optionally not set them with another flag but in most cases where people are using colortool they don't want a bright pink/purple background in their PowerShell windows!!! Just because the out of the PowerShell selects a non-default color for the background (I've never understood the hard to read choice of dark blue), doesn't mean that the colortool can't be more sensible. I consider the current behavior of making one of the two built in shell programs unreadable to be a major bug.

claunia commented

@parkovski commented on GitHub (Nov 5, 2017):

That would definitely help, but it still doesn't fix the scenario where a theme defines two similar colors with a separate background color. In iTerm the default background color (same with default foreground) is a different setting than any of the colors settable through escape sequences. The only real fix for this is for the Windows console to also provide totally separate foreground/background color options.

@parkovski commented on GitHub (Nov 5, 2017): That would definitely help, but it still doesn't fix the scenario where a theme defines two similar colors with a separate background color. In iTerm the default background color (same with default foreground) is a different setting than any of the colors settable through escape sequences. The only real fix for this is for the Windows console to also provide totally separate foreground/background color options.

claunia commented

@zadjii-msft commented on GitHub (Feb 12, 2018):

As you've all mentioned here, essentially, the console doesn't have a separate "Background Color" separate from the color table - it uses one entry of the color table as it's "background color". So if the itermcolors scheme has a different background color from the black color, then the applied scheme is going to look different. It's as close as we can get to what's in the scheme with what conhost can do.

I absolutely want to fix this, but unfortunately its a pretty massive change to the codebase that'd be hard to get signed off on.

I will keep this issue open to track the feature request, hopefully we'll find some time to do it.

@zadjii-msft commented on GitHub (Feb 12, 2018): As you've all mentioned here, essentially, the console doesn't have a separate "Background Color" separate from the color table - it uses one entry of the color table as it's "background color". So if the itermcolors scheme has a different background color from the black color, then the applied scheme is going to look different. It's as close as we can get to what's in the scheme with what conhost can do. I absolutely want to fix this, but unfortunately its a pretty massive change to the codebase that'd be hard to get signed off on. I will keep this issue open to track the feature request, hopefully we'll find some time to do it.

claunia commented

@wavebeem commented on GitHub (Feb 12, 2018):

Understandable. No worries, and thanks for looking into this.

@wavebeem commented on GitHub (Feb 12, 2018): Understandable. No worries, and thanks for looking into this.

claunia commented

@yatli commented on GitHub (Feb 13, 2018):

Hello friends,

Will it be acceptable if we calculate the nearest color in a slot to the background, and set the background to that slot?
Also we can apply subtle adjustments to the color scheme itself to keep everything as close to the original as possible.

This is obviously just a workaround but does not need a lot of effort in the backstage. Essentially we are only trying to approximate 18 colors with 16. There's been a vim plugin for approximating a 256 color theme with only 16 colors so I think this approach will definitely work out.

@yatli commented on GitHub (Feb 13, 2018): Hello friends, Will it be acceptable if we calculate the nearest color in a slot to the background, and set the background to that slot? Also we can apply subtle adjustments to the color scheme itself to keep everything as close to the original as possible. This is obviously just a workaround but does not need a lot of effort in the backstage. Essentially we are only trying to approximate 18 colors with 16. There's been a vim plugin for approximating a 256 color theme with only 16 colors so I think this approach will definitely work out.

claunia commented

@segevfiner commented on GitHub (Feb 13, 2018):

Obviously, setting the background color independently of the 16 color
palette is the true fix. But that's a change in Window's console that can
take a very long time to materialise and land.

But before that, there are some improvements that can be made to make
colortool quite a workable solution.

For starters, it needs to gain the ability to set the background/foreground
color index from the 16-color pallete at all. So as to avoid the issue with
Powershell, and be able to restore the powershell default theme. I'm not
sure if there is a public API for this currently though.

Secondly, it needs handling for console settings saved in shortcuts (lnk)
files, either by wiping them, or saving settings to them (Preferably as a
command that can be used on user created shortcuts in addition to any
hardcoded list of default shortcuts). The similar concfg project has a
command to wipe them.

Third, it needs handling for the multiple saved console settings in the
registry. Allowing to set a color scheme globally but maybe even better is
a way to list, delete, etc. such settings.

For selecting the background/foreground color to set. You can always decide
to extend the color scheme files that you use. I don't think you are bound
in any way to support some upstream color scheme format exactly. This gives
the users the control to adapt a theme to this Windows console limitation
in the best way they see rather than trying to guess around that.
Guessing/Auto detection can be used for color schemes that don't use such
extensions to give a better result still. But that sounds like something
you add after the basics work well.

On Tue, Feb 13, 2018 at 6:18 AM, Yatao Li notifications@github.com wrote:

Hello friends,

Will it be acceptable if we calculate the nearest color in a slot to the
background, and set the background to that slot?
Also we can apply subtle adjustments to the color scheme itself to keep
everything as close to the original as possible.

This is obviously just a workaround but does not need a lot of effort in
the backstage. Essentially we are only trying to approximate 18 colors with
16. There's been a vim plugin for approximating a 256 color theme with only
16 colors so I think this approach will definitely work out.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/console/issues/23#issuecomment-365146331,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXlg__rSAUN1-tEiMbE7VZPpeQcJFN8Bks5tUQ0ngaJpZM4PDiaR
.

@segevfiner commented on GitHub (Feb 13, 2018): Obviously, setting the background color independently of the 16 color palette is the true fix. But that's a change in Window's console that can take a very long time to materialise and land. But before that, there are some improvements that can be made to make colortool quite a workable solution. For starters, it needs to gain the ability to set the background/foreground color index from the 16-color pallete at all. So as to avoid the issue with Powershell, and be able to restore the powershell default theme. I'm not sure if there is a public API for this currently though. Secondly, it needs handling for console settings saved in shortcuts (lnk) files, either by wiping them, or saving settings to them (Preferably as a command that can be used on user created shortcuts in addition to any hardcoded list of default shortcuts). The similar concfg project has a command to wipe them. Third, it needs handling for the multiple saved console settings in the registry. Allowing to set a color scheme globally but maybe even better is a way to list, delete, etc. such settings. For selecting the background/foreground color to set. You can always decide to extend the color scheme files that you use. I don't think you are bound in any way to support some upstream color scheme format exactly. This gives the users the control to adapt a theme to this Windows console limitation in the best way they see rather than trying to guess around that. Guessing/Auto detection can be used for color schemes that don't use such extensions to give a better result still. But that sounds like something you add after the basics work well. On Tue, Feb 13, 2018 at 6:18 AM, Yatao Li <notifications@github.com> wrote: > Hello friends, > > Will it be acceptable if we calculate the nearest color in a slot to the > background, and set the background to that slot? > Also we can apply subtle adjustments to the color scheme itself to keep > everything as close to the original as possible. > > This is obviously just a workaround but does not need a lot of effort in > the backstage. Essentially we are only trying to approximate 18 colors with > 16. There's been a vim plugin for approximating a 256 color theme with only > 16 colors so I think this approach will definitely work out. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/Microsoft/console/issues/23#issuecomment-365146331>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AXlg__rSAUN1-tEiMbE7VZPpeQcJFN8Bks5tUQ0ngaJpZM4PDiaR> > . >

claunia commented

@zadjii-msft commented on GitHub (Feb 13, 2018):

I'm not going to be able to commit to being able to set the FG/bG independently from the color table. I'd LOVE to implement it, yes, but yea, it's a lot of work.
Yes, setting the FG/BG indicies with colortool would be a welcome improvement. Adding entries to the .ini format wouldn't be hard, setting the colors themselves would be easy, and finding the nearest color from a .itermcolors file would be relatively trivial as well. I'd welcome the contribution.
Right now, if you use colortool to set the console properties, then open the propsheet and hit okay, they'll persist to the shortcut if you were launched from a shortcut. I'd say that wiping shortcut entries is not really in the scope of the colortool project. I'd rather keep it more focused.
That's a bit bigger of an ask, it'd be a pretty major enhancement of our settings infrastructure. Man, if only I had a spec for such a feature, like, maybe sitting in a file share somewhere, ready to implement.... cough @bitcrazed cough

TLDR if someone wants to implement finding the nearest table entry to the itermcolors fg/bg and set the selected fg/bg to that, I'd welcome the PR.

@zadjii-msft commented on GitHub (Feb 13, 2018): 0. I'm not going to be able to commit to being able to set the FG/bG independently from the color table. I'd LOVE to implement it, yes, but yea, it's a lot of work. 1. Yes, setting the FG/BG indicies with colortool would be a welcome improvement. Adding entries to the .ini format wouldn't be hard, setting the colors themselves would be easy, and finding the nearest color from a .itermcolors file would be relatively trivial as well. I'd welcome the contribution. 2. Right now, if you use colortool to set the console properties, then open the propsheet and hit okay, they'll persist to the shortcut if you were launched from a shortcut. I'd say that wiping shortcut entries is not really in the scope of the colortool project. I'd rather keep it more focused. 3. That's a bit bigger of an ask, it'd be a pretty major enhancement of our settings infrastructure. Man, if only I had a spec for such a feature, like, maybe sitting in a file share somewhere, ready to implement.... *cough* @bitcrazed *cough* TLDR if someone wants to implement finding the nearest table entry to the itermcolors fg/bg and set the selected fg/bg to that, I'd welcome the PR.

claunia commented

@yatli commented on GitHub (Feb 14, 2018):

@zadjii-msft there you go: https://github.com/Microsoft/console/pull/66

@yatli commented on GitHub (Feb 14, 2018): @zadjii-msft there you go: https://github.com/Microsoft/console/pull/66

claunia commented

@nickjj commented on GitHub (Dec 8, 2018):

I'm using the October 2018 release and the background colors are still very much not what they should be. This is also with Microsoft Windows [Version 10.0.17763.134] and the stock ubuntu.exe terminal.

For example, I want to use the Tomorrow scheme which is a light background theme, but ColorTool is using a completely different color scheme than what Tomorrow is defined as in the XML file.

Here's a screenshot of a bunch of schemes I downloaded (just to experiment):

But here's what Tomorrow should look like: https://github.com/mbadolato/iTerm2-Color-Schemes#tomorrow

Any ideas on how to get around this? There's not a single white background scheme that works due to the color tool not loading in the correct colors.

@nickjj commented on GitHub (Dec 8, 2018): I'm using the October 2018 release and the background colors are still very much not what they should be. This is also with Microsoft Windows [Version 10.0.17763.134] and the stock `ubuntu.exe` terminal. For example, I want to use the `Tomorrow` scheme which is a light background theme, but ColorTool is using a completely different color scheme than what Tomorrow is defined as in the XML file. Here's a screenshot of a bunch of schemes I downloaded (just to experiment): ![image](https://user-images.githubusercontent.com/813219/49687633-df86d880-fad3-11e8-8c49-b15910758452.png) But here's what Tomorrow should look like: https://github.com/mbadolato/iTerm2-Color-Schemes#tomorrow Any ideas on how to get around this? There's not a single white background scheme that works due to the color tool not loading in the correct colors.

claunia commented

@zadjii-msft commented on GitHub (Dec 10, 2018):

Could you be more specific? I mean, this looks like it's just fine to me:

Do you mean the "default" foreground and background colors from the itermcolors file? (I think the background is defined under `Background Color

*Nix style terminals support foreground and background colors outside the values from the color table, but conhost doesn't support that unfortunately. With conhost, the fg/bg colors must be an index into the color table, so we ignore those values from the itermcolors file.

Stay tuned in this area - we might have some news soon^tm

@zadjii-msft commented on GitHub (Dec 10, 2018): Could you be more specific? I mean, this looks like it's just fine to me: ![image](https://user-images.githubusercontent.com/18356694/49745441-cefd6c00-fc53-11e8-84c2-10d95f14b201.png) Do you mean the "default" foreground and background colors from the itermcolors file? (I think the background is defined under `<key>Background Color</key> *Nix style terminals support foreground and background colors outside the values from the color table, but conhost doesn't support that unfortunately. With conhost, the fg/bg colors must be an index into the color table, so we ignore those values from the itermcolors file. Stay tuned in this area - we might have some news soon<sup>tm</sup>

claunia commented

@nickjj commented on GitHub (Dec 10, 2018):

Specifically, with the ubuntu.exe terminal and not modifying anything extra in the Properties:

Download https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/schemes/Tomorrow.itermcolors
Place the file into the ColorTool's schemes/ folder
Run ./ColorTools -b Tomorrow
Open a new terminal

I end up with a black background and the colors do not match the white background that is supposed to show up with the Tomorrow theme. Every single iTerm2 theme listed in that git repo with a white background ends up with a black background.

Is there anything I can change on my end to get the correct foreground and background colors to take effect today using Windows 10 Pro stable (I'm not interested in using insiders)? You must have done something extra to get it to look fine for you.

Edit:

Also, the Solarized light theme that comes with ColorTools properly sets a different background color other than black, without doing anything extra, but I'm unable to understand why that happens but doesn't happen with Tomorrow (or any other white background iTerm theme). Both of them have the same exact keys in the XML file.

@nickjj commented on GitHub (Dec 10, 2018): Specifically, with the `ubuntu.exe` terminal and not modifying anything extra in the Properties: 1. Download https://github.com/mbadolato/iTerm2-Color-Schemes/blob/master/schemes/Tomorrow.itermcolors 2. Place the file into the ColorTool's `schemes/` folder 3. Run `./ColorTools -b Tomorrow` 4. Open a new terminal I end up with a black background and the colors do not match the white background that is supposed to show up with the Tomorrow theme. Every single iTerm2 theme listed in that git repo with a white background ends up with a black background. Is there anything I can change on my end to get the correct foreground and background colors to take effect today using Windows 10 Pro stable (I'm not interested in using insiders)? You must have done something extra to get it to look fine for you. **Edit:** Also, the Solarized light theme that comes with ColorTools properly sets a different background color other than black, without doing anything extra, but I'm unable to understand why that happens but doesn't happen with Tomorrow (or any other white background iTerm theme). Both of them have the same exact keys in the XML file.

claunia commented

@stuaxo commented on GitHub (Feb 22, 2019):

Suffering in a workplace where I can't download colortool - boo.

Having said that, having a page in the settings where you could choose from colour themes would be a lot nicer than clicking around and editing individual colours.

@stuaxo commented on GitHub (Feb 22, 2019): Suffering in a workplace where I can't download colortool - boo. Having said that, having a page in the settings where you could choose from colour themes would be a lot nicer than clicking around and editing individual colours.

claunia commented

@zadjii-msft commented on GitHub (Feb 22, 2019):

@nickjj Up until recently, the Windows Console didn't support "default colors" separate from the rest of the color table. So, if your selected default background color was black before running colortool, it'll still be black after running colortool, just with whatever the new entry for black is.

Even though we've experimentally added support for true terminal-style default colors (in recent Insiders builds), Colortool hasn't yet been updated to add support for them yet.

@stuaxo We definitely feel the pain too, but unfortunately adding support for proper color schemes w/in conhost itself is unfortunately far down our backlog :(. It's just too much work to justify compared to other higher priority work items.

@zadjii-msft commented on GitHub (Feb 22, 2019): @nickjj Up until recently, the Windows Console didn't support "default colors" separate from the rest of the color table. So, if your selected default background color was black before running colortool, it'll still be black after running colortool, just with whatever the new entry for black is. Even though we've experimentally added support for true terminal-style default colors (in recent Insiders builds), Colortool hasn't yet been updated to add support for them yet. @stuaxo We definitely feel the pain too, but unfortunately adding support for proper color schemes w/in conhost itself is unfortunately far down our backlog :(. It's just too much work to justify compared to other higher priority work items.

claunia commented

@stuaxo commented on GitHub (Feb 22, 2019):

Cool, well if it's actually on the backlog that's nice - hopefully it'll arrive one day as a pleasant surprise.

What triggered this is, that at my workplace there is some setup with powershell->docker->??->a bash shell.

Sometimes I'll be in vim editing a file and the foreground and background are the same for some colours:
(unless I'm being colourblind??)

The bit between psql and -c is actually the string $POSTGRES_URL

The setup is all a bit locked down (the shell is launched by divio client, then the file is in another docker-layer). I end up editing the file then cating it to see if it's correct.

Since I'm in some ephemeral container, editing the vim config is tricky ... I assume that if this was running under a terminal like vte I wouldn't have the issue + it probably comes down to limitations in the windows console host.

@stuaxo commented on GitHub (Feb 22, 2019): Cool, well if it's actually on the backlog that's nice - hopefully it'll arrive one day as a pleasant surprise. What triggered this is, that at my workplace there is some setup with powershell->docker->??->a bash shell. Sometimes I'll be in vim editing a file and the foreground and background are the same for some colours: (unless I'm being colourblind??) The bit between `psql` and `-c` is actually the string $POSTGRES_URL ![image](https://user-images.githubusercontent.com/179677/53261027-e97ba900-36ca-11e9-8265-7cfbc0486116.png) The setup is all a bit locked down (the shell is launched by divio client, then the file is in another docker-layer). I end up editing the file then `cat`ing it to see if it's correct. Since I'm in some ephemeral container, editing the vim config is tricky ... I assume that if this was running under a terminal like vte I wouldn't have the issue + it probably comes down to limitations in the windows console host.

claunia commented

@Biswa96 commented on GitHub (Feb 22, 2019):

@stuaxo How about this trick? Run the colortool in your PC/Laptop. Export and Copy HKCU\Console registry key to your workplace and import that registry values. Backup your previous registry and ask for permission to change registry before trying this in workplace. Also this is not a "recommend" way.

@Biswa96 commented on GitHub (Feb 22, 2019): @stuaxo How about this trick? Run the colortool in your PC/Laptop. Export and Copy `HKCU\Console` registry key to your workplace and import that registry values. Backup your previous registry and ask for permission to change registry before trying this in workplace. Also this is not a "recommend" way.

claunia commented

@stuaxo commented on GitHub (Feb 22, 2019):

Cheers I'll give that a go on monday. The worst thing about the colourscheme shown is the dark blue with red on top - I just can't read most of the things that appear like that - I assume it's some powershell default ?

@stuaxo commented on GitHub (Feb 22, 2019): Cheers I'll give that a go on monday. The worst thing about the colourscheme shown is the dark blue with red on top - I just can't read most of the things that appear like that - I assume it's some powershell default ?

claunia commented

@zadjii-msft commented on GitHub (Feb 22, 2019):

Oh, that's definitely because the powershell background color, the "powershell blue" is actually using the "dark_magenta" table entry.

Powershell's default colors are totally wonky. I'd personally change the properties for your powershell window from having "dark_magenta" as the default background to the "black" entry.

As an example, compare my cmd vs powershell settings:

Cmd on the left has the 0'th index set as my default background, while powershell has the fifth index, which is magenta in cmd, but powershell has overwritten with dark blue.

The "invisible text" that your seeing (or not seeing in this case) is because vim is printing the text in dark_magenta, which doesn't appear against the dark_magenta background.

@zadjii-msft commented on GitHub (Feb 22, 2019): Oh, that's definitely because the powershell background color, the "powershell blue" is actually using the "dark_magenta" table entry. Powershell's default colors are totally wonky. I'd personally change the properties for your powershell window from having "dark_magenta" as the default background to the "black" entry. As an example, compare my cmd vs powershell settings: ![image](https://user-images.githubusercontent.com/18356694/53261498-0becd280-3689-11e9-9e5b-64053730859f.png) Cmd on the left has the 0'th index set as my default background, while powershell has the fifth index, which is magenta in cmd, but powershell has overwritten with dark blue. The "invisible text" that your seeing (or not seeing in this case) is because vim is printing the text in dark_magenta, which doesn't appear against the dark_magenta background.

claunia commented