terminal: Vim background color renders incorrectly

The common fix is to disable Vim’s “Background Color Erase (BCE)” option by setting t_ut to an empty string, like this:

:set t_ut=“” (then CTRL-L to re-draw)

This tells Vim to erase areas of the screen, as it does when back-scrolling, using the current background color (from the Vim color scheme) instead of relying on that specific Terminal’s implementation of Background Color Erase (BCE) mode. Otherwise, areas are simply erased without regard for background color, which means the Terminal’s DEFAULT background value would be used.

Exactly. Well, it can also happen if t_Co=256 and/or term=xterm

Also, to prevent those flashes of the wrong bg color during rapid scrolling when bce mode is disabled, you’ll want to additionally configure the maximum number of lines that vim will scroll before redrawing the screen. Set it to 1 line. The following works well placed in a vimrc file:

if (&term =~ '^xterm' && &t_Co == 256)
  set t_ut= | set ttyscroll=1
endif

I’m think Microsoft/WSL #1706 was maybe an end-of-line/newline erase bug or something like that, but Microsoft/Terminal #70 sounds like the same Vim bce issue we’re discussing here.

I am experiencing similar issues using vim in Windows Terminal 1.2.2381.0. As you can see, guifg and guibg are set to NONE, but the background is being painted black. This is definitely not Windows Terminal’s background color, which was explicitly set to match the chosen vim theme. Notably, this problem appears to be specific to Windows and does not occur in WSL:

On Windows 10 1903 (18362.175) with WSL Ubuntu 18.04, the @xtremeperf workarounds involving set t_ut did not work for me. I found another workaround in an answer to a stack overflow question. In ~/.vimrc put:

highlight Normal ctermfg=black ctermbg=lightgrey

When in vim, this sets the text color to black and the background color to lightgrey. Other colors are listed in /usr/share/vim/vim80/rgb.txt Not all those colors are supported on a 256 color xterm.

This issue should be reopened as it is NOT resolved.

🎉This issue was addressed in #2668, which has now been successfully released as Windows Terminal Preview v0.5.2661.0.🎉

Handy links:

• Release Notes
• Store Download

https://vi.stackexchange.com/questions/17464/24-bit-256-colorscheme-in-windows-console add this line set termguicolors to .vimrc worked for me

Note that you are setting the background to color 7 (and not to a true-color or 16-256 terminal colors) using lightgrey, which you can see in :help cterm-colors in Vim. As I noted above, this problem only occurs if the background color is set to either >=16 or an RGB value.

This looks very similar to issue #70 - might be a duplicate. What is happening when you scroll, is you get a delete lines (DL) or insert lines (IL) escape sequence, which should fill the new space with the current background color, but it doesn’t work correctly when using colors from the 256-color palette or RGB mode. A simple test case would be something like this:

printf "\ec\e[1;10r\e[H\e[48;5;2m\e[10M\nBG COLOR\e[r\e[m"

That sets a scroll region of 10 lines, and then erases those 10 lines with a green background color from the 256-color palette. While the BG COLOR text shows what the color should have been, the background is actually filled with black. If you replace the \e[48;5;2m sequence with the simpler 16-color sequence \e[42m it’ll work.

printf "\ec\e[1;10r\e[H\e[42m\e[10M\nBG COLOR\e[r\e[m"

The reason for the failure can be found in the DoSrvPrivateModifyLinesImpl method, which calls the ScrollConsoleScreenBufferWImpl method to handle the scrolling. The latter only accepts legacy 16-color attributes, so it tries to derive an appropriate value using the TextAttribute::GetLegacyAttributes method. Unfortunately that method is essentially useless for anything that isn’t already a legacy color.

That said, the ScrollConsoleScreenBufferWImpl does try to make up for the limitations of the API, and map the 16-color attributes back to their original RGB values. It does this by comparing the legacy value against the legacy equivalent of the current colors - if they match then it will use the full RGB values of the current colors. Unfortunately this doesn’t work because it uses a different calculation for the legacy attributes (the Settings::GenerateLegacyAttributes method).

Assuming the ScrollConsoleScreenBufferWImpl can’t be updated to handle full RGB attributes, the next best thing would be to use a better legacy attribute calculation in the DoSrvPrivateModifyLinesImpl method. If we were to use the same Settings::GenerateLegacyAttributes on both ends then the mapping back to RGB should work correctly. And in the event it can’t map, because it really doesn’t match the current color, then it should at least give a better approximation of the requested color.