Something wrong with the vim colorshemes

[aeilot]

Environment

Windows build number:  10.0.19042.0
Windows Terminal version (if applicable): 1.0.1811.0
VIM: 8.2

Steps to reproduce

I installed onedark.vim colorscheme for vim.

But the colorscheme doesn't work correctly as I saw on my Mac.

By the way, I am using the Terminal colorscheme snazzy.

Here's it's config:

		{
				"name": "Snazzy",
				"black": "#000000",
				"red": "#fc4346",
				"green": "#50fb7c",
				"yellow": "#f0fb8c",
				"blue": "#49baff",
				"purple": "#fc4cb4",
				"cyan": "#8be9fe",
				"white": "#ededec",
				"brightBlack": "#555555",
				"brightRed": "#fc4346",
				"brightGreen": "#50fb7c",
				"brightYellow": "#f0fb8c",
				"brightBlue": "#49baff",
				"brightPurple": "#fc4cb4",
				"brightCyan": "#8be9fe",
				"brightWhite": "#ededec",
				"background": "#1e1f29",
				"foreground": "#ebece6"
		}

	        "acrylicOpacity": 0.7,
                "colorScheme" : "Snazzy",
                "cursorColor" : "#000000",
                "fontFace" : "MesloLGL Nerd Font",
                "useAcrylic": true

Expected behavior

This is what onedark.vim really looks like:

Actual behavior

But it looks like this here:

[DHowett]

This is a version of #293 that is not fixed by #6698 #6506. vim.exe achieves setting this "background" by explicitly redefining what the console color at index 0 means. This is actually worse after #6506 because we're better about exposing the drawing operations of the application to the terminal, and we still believe console color 0 to be the "background". When an application uses the legacy console API to set the colors, we drop the background and foreground out so the acrylic can shine through.

This is very dangerously close to acting by design and might need a fix in vim.exe.

[gordonmessmer]

Is there a preview build that includes 6698 and 6506?

[zadjii-msft]

@gordonmessmer at this point, the 1.2 preview should be out that includes those changes.

[zadjii-msft]

I'm thinking that we might be able to fix this if we had conpty listen for changes to the color table, and emit those with the OSC sequences for setting the color table. I don't think this is the right solution - vim.exe could definitely just fix this on their end. But this is an option that's available to us

[aeilot]

Thanks for replying!

On KDE, the Yakuake Terminal, which also contains the feature of acrylic, does like this:

On Mac, it looks like this as well.

Maybe we can do as they do. What I think about it is, when the user opens special apps like vim, we can disable this feature or etc.

[DHowett]

This is because on those platforms Vim uses VT sequences, but on Windows it does not. If you use Vim inside WSL you can see that it will work the same way 😄

[j4james]

I'm thinking that we might be able to fix this if we had conpty listen for changes to the color table, and emit those with the OSC sequences for setting the color table.

I don't think this will help. I wrote a patch to fix issue #2985 that does something like this, and it makes no difference to vim. The underlying problem is that the console API can't differentiate between a black background and default, so we treat them as the same thing (that is they're both interpreted as default). So it doesn't matter what the palette color for black is set to - a black background is still going to be interpreted as default, and thus will always be transparent (if you have acrylic enabled).