MacVim/GUI :terminal doesn't set Terminal background

Question

MacVim/GUI :terminal doesn't set Terminal background

craigmac opened this issue 2 years ago · 31 comments

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

Answer 1 · 2022-07-25T18:22:06.000Z

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

Answer 2 · 2022-07-25T18:51:35.000Z

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.

Answer 3 · 2022-07-25T18:54:56.000Z

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

Answer 4 · 2022-07-25T18:57:55.000Z

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

Answer 5 · 2022-07-25T18:58:26.000Z

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.

Answer 6 · 2022-07-25T18:59:21.000Z

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.

Answer 7 · 2022-07-25T19:00:14.000Z

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.

Answer 8 · 2022-07-25T19:06:27.000Z

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.

Answer 9 · 2022-07-25T19:09:43.000Z

Not sure about macvim, in gvim:

colo desert in vimfiles/vimrc:

colo desert in vimfiles/gvimrc:

Answer 10 · 2022-07-25T19:14:13.000Z

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.

Answer 11 · 2022-07-26T07:15:42.000Z

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

Answer 12 · 2022-07-26T07:29:02.000Z

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

Answer 13 · 2022-07-26T07:35:27.000Z

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

Answer 14 · 2022-07-26T07:36:22.000Z

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

Answer 15 · 2022-07-26T07:50:48.000Z

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

Answer 16 · 2022-07-26T08:06:38.000Z

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:

remove _tcozero,
ask @lifepillar for a different check.

Answer 17 · 2022-07-26T08:10:48.000Z

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.

Answer 18 · 2022-07-26T08:43:59.000Z

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

Answer 19 · 2022-07-26T08:46:30.000Z

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.

Answer 20 · 2022-07-26T08:53:43.000Z

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

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

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

Answer 21 · 2022-07-26T10:16:08.000Z

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

Answer 22 · 2022-07-26T10:27:12.000Z

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

remove _tcozero
colortemplate to explicitly check for t_Co == 0

Answer 23 · 2022-07-26T12:27:03.000Z

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

It works for me so far...

Answer 24 · 2022-07-26T13:03:22.000Z

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

Answer 25 · 2022-07-26T13:04:21.000Z

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

Answer 26 · 2022-08-21T17:20:16.000Z

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

Answer 27 · 2022-08-21T21:39:26.000Z

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

Answer 28 · 2022-08-22T10:31:29.000Z

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

Answer 29 · 2022-08-22T10:32:20.000Z

This was the thread that landed me here, I believe

Answer 30 · 2022-08-22T11:03:07.000Z

@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

Answer 31 · 2022-08-22T11:05:55.000Z

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! 🙇