MacVim/GUI :terminal doesn't set Terminal background

[craigmac]

Initially reported there. I've tried several of the new ones, and they all have the same issue, the terminal background color is not set. Sometimes this looks ok, but sometimes the terminal buffer becomes unreadable (blue.vim for instance).

[habamax]

Try to set colorscheme in gvimrc

I think 5he issue is with links. Terminal is explicitly linked to normal but it is reset by GUI for some reason. At least I've seen 5his in windows gvim

[craigmac]

Yes, definitely seems to be because of the GUI resets that are done, as this only happens in the GUI (at least in MacVim). It happens for all the colorschemes from the new batch that I've tried. The fix is explicitly setting the guibg to the intended color in my vimrc with:

augroup Vimrc
    autocmd!
    autocmd ColorScheme apprentice hi! Terminal guibg=#262626
augroup END

I don't know what the solution would be to fix it in all the colorschemes - maybe setting some kind of onetime autocmd? That's pretty hacky, though. I guess detected has('gui_running') would work better, provided the same bug is happening on Gvim, which I can't confirm.

[habamax]

A workaround would be to explicitly set all hl groups without links, but I would fill a bug report against vim.

[craigmac]

I did here, should I reopen or create a new one?

[romainl]

Maybe MacVim, not Vim. I use MacVim too and I don't have those issues at all, maybe because I quickly stopped using a gvimrc after all the ancient troubles with colorschemes in MacVim.

[habamax]

I did here, should I reopen or create a new one?

It is a bit different -- the issue is about links that are being reset/cleared by gui.

[habamax]

Maybe MacVim, not Vim. I use MacVim too and I don't have those issues at all, maybe because I quickly stopped using a gvimrc after all the ancient troubles with colorschemes in MacVim.

The issue with gvim is that if you have set colorscheme in .vimrc, links are cleared, if in .gvimrc -- they are ok.

[romainl]

The issue with gvim is that if you have set colorscheme in .vimrc, links are cleared, if in .gvimrc -- they are ok.

And yet here it works fine,

• without a gvimrc,
• with colorscheme apprentice in vimrc.

[habamax]

Not sure about macvim, in gvim:

colo desert in vimfiles/vimrc:

colo desert in vimfiles/gvimrc:

[romainl]

Hmm OK, I can finally reproduce the bug.

Problem: malotru doesn't exhibit the same issue despite having the exact same hi! link Terminal Normal as apprentice. Here it is in MacVim, with the Normal background set to something very obvious just for the example:

:term gets the same bg color as Normal.

[habamax]

@craigmac @romainl I have created a separate issue for this in vim.

[habamax]

@romainl, @neutaaaaan I've found the root cause in our colorschemes.

@romainl if you strip down your apprentice (and remade colorschemes) to this:

set background=dark

hi clear
let g:colors_name = 'apprentice'

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 1

let g:terminal_ansi_colors = ['#1c1c1c', '#af5f5f', '#5f875f', '#87875f', '#5f87af', '#5f5f87', '#5f8787', '#6c6c6c', '#444444', '#ff8700', '#87af87', '#ffffaf', '#87afd7', '#8787af', '#5fafaf', '#ffffff']
hi Normal guifg=#bcbcbc guibg=#ff0000 gui=NONE cterm=NONE
hi! link Terminal Normal

if s:t_Co >= 0
  hi Terminal term=NONE
  unlet s:t_Co
  finish
endif

You will see that hi Terminal term=NONE -- and this exact line breaks terminal background for us...

[habamax]

@lifepillar, is it possible to have t_Co check with explicit == ?

[habamax]

On the other hand, we can just remove Terminal from _tcozero, right?

[habamax]

Quick test -- removing Terminal from _tcozero solves the issue for me.

[romainl]

Oh god, I stared at that

if s:t_Co >= 0
  hi Terminal term=NONE
  unlet s:t_Co
  finish
endif

for a while assuming that there were other finish above but there weren't.

Options:

1. remove _tcozero,
2. ask @lifepillar for a different check.

[habamax]

I would remove _tcozero as the usecase most users will probably never meet. And if they are in this situation, let them use default vim experience.

[habamax]

let me actually do this, if you don't mind

[neutaaaaan]

I'd much rather find a proper fix for that, as this is the noisy mess that default cakes on the screen.

"Most users won't ever use it" is not a rationale, it's a cop-out. I could say that about half of what is in this repository.

[habamax]

@neutaaaaan for some reason, your quiet.vim doesn't define it... :)

Anyway, a proper fix would take quite a time if at all -- it might be considered as not a bug in vim repo (term=NONE clears terminal link).

So we have following options to workaround it:

1. remove _tcozero until fix would be in vim
2. remove only Terminal from _tcozero
3. ask @lifepillar to add explicit checks of t_Co.

Pt. 3 might also take quite a while...

[habamax]

and 2. is not an option actually, as it breaks other links too (e.g. EndOfBuffer).

[habamax]

so we have only those options (before "proper" fix):

• remove _tcozero
• colortemplate to explicitly check for t_Co == 0

[habamax]

So I went "fixing colortemlate" route, added strict comparisson if t_Co is 0.

It works for me so far...

[habamax]

The issue might be easily fixed by adjusting (which I did in PR)

Following t_Co detection from

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 1

to

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co >= 0 ? &t_Co : -1

Basically, when "gui_running" &t_Co is undefined and we set s:t_Co to 1. Which is then always matches with s:t_Co >= 0

[habamax]

All colorschemes were regenerated, @craigmac could you check it too (in PR here)?

[ppseprus]

So.. will a fix be eventually shipped w/ some later macos software update? Does anyone know? 🤔

[romainl]

@ppseprus a fix of what, exactly?

The colorschemes we are working on here—and the fixes we may apply to them—are all meant to be part of Vim's main distribution at some point. Vim's author does runtime updates from time to time so it is impossible to give you an estimation. That said, I wouldn't count on Apple to ship a new Vim build as part of a software update.

On macOS, MacVim is your best bet anyway because /usr/bin/vim is always one or two versions late.

[ppseprus]

Hm 🤔 I might have misunderstood this thread.

I was searching for an issue that appeared for me with macOS 12.5. The colorscheme slate together with syntax on started displaying things differently. I was searching for this on macos blogs and got dropped in, but maybe I somehow mixed up the threads.

My vim version is as follows

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jun 17 2022 21:26:11)
macOS version - arm64
Included patches: 1-5032
Compiled by root@apple.com

Unfortunately, I dont have screenshots from the previous state, nor do I know what vim version was installed before... 😞

[ppseprus]

This was the thread that landed me here, I believe

[neutaaaaan]

@ppseprus Here's the long version

tl;dr The default colorschemes were shoddily put together to say the least, and users got used to the particular way they broke on their systems. Slate was one of the worst of the bunch. By making it more consistent across environments, we broke user expectations. If you really, really, really want the old behaviour back, you can find the old files here

[ppseprus]

I understand now! If you say this was intentional, I will find a way to adjust my configurations! 😉 Thanks @neutaaaaan for clearing this up in my head! 🙇