Skip to main content
added 310 characters in body
Source Link
Martin Tournoij
  • 63.3k
  • 26
  • 199
  • 274

The problem is that there are various scenarios in which Vim will reload the colour scheme such as using :colorscheme or :syntax enable.

Colour schemes should always start with :highlight clear to clear all existing highlight groups. Why? See what happens when you do:

:highlight Test ctermfg=red
:highlight Test ctermbg=blue

What is Test now set to?


To fix this, you should always hook in to the ColorScheme autocommand when you define highlight groups:

fun! s:highlight()
    highlight Foo ctermbg=red
endfun

augroup myplugin_highlight
  autocmd!
  autocmd ColorScheme * call s:highlight()
augroup end
call s:highlight()

I used a function because we want to run this both on startup and when the ColorScheme autocommand is fired.

It's a bit ugly, but it's the only way.


The reason this breaks when putting colorscheme inside gvimrc, but not vimrc, is because of the load order. In :help startup we can see that:

  • Loading the vimrc is step 3
  • Loading plugins is step 4
  • Loading gvimrc is step 8.

So the gvimrc file will override plugins, but vimrc won't. This is also why you shouldn't put things like g:some_plugin_setting in the gvimrc file.

The problem is that there are various scenarios in which Vim will reload the colour scheme such as using :colorscheme or :syntax enable.

Colour schemes should always start with :highlight clear to clear all existing highlight groups. Why? See what happens when you do:

:highlight Test ctermfg=red
:highlight Test ctermbg=blue

What is Test now set to?


To fix this, you should always hook in to the ColorScheme autocommand when you define highlight groups:

fun! s:highlight()
    highlight Foo ctermbg=red
endfun

augroup myplugin_highlight
  autocmd!
  autocmd ColorScheme * call s:highlight()
augroup end
call s:highlight()

I used a function because we want to run this both on startup and when the ColorScheme autocommand is fired.

It's a bit ugly, but it's the only way.

The problem is that there are various scenarios in which Vim will reload the colour scheme such as using :colorscheme or :syntax enable.

Colour schemes should always start with :highlight clear to clear all existing highlight groups. Why? See what happens when you do:

:highlight Test ctermfg=red
:highlight Test ctermbg=blue

What is Test now set to?


To fix this, you should always hook in to the ColorScheme autocommand when you define highlight groups:

fun! s:highlight()
    highlight Foo ctermbg=red
endfun

augroup myplugin_highlight
  autocmd!
  autocmd ColorScheme * call s:highlight()
augroup end
call s:highlight()

I used a function because we want to run this both on startup and when the ColorScheme autocommand is fired.

It's a bit ugly, but it's the only way.


The reason this breaks when putting colorscheme inside gvimrc, but not vimrc, is because of the load order. In :help startup we can see that:

  • Loading the vimrc is step 3
  • Loading plugins is step 4
  • Loading gvimrc is step 8.

So the gvimrc file will override plugins, but vimrc won't. This is also why you shouldn't put things like g:some_plugin_setting in the gvimrc file.

Source Link
Martin Tournoij
  • 63.3k
  • 26
  • 199
  • 274

The problem is that there are various scenarios in which Vim will reload the colour scheme such as using :colorscheme or :syntax enable.

Colour schemes should always start with :highlight clear to clear all existing highlight groups. Why? See what happens when you do:

:highlight Test ctermfg=red
:highlight Test ctermbg=blue

What is Test now set to?


To fix this, you should always hook in to the ColorScheme autocommand when you define highlight groups:

fun! s:highlight()
    highlight Foo ctermbg=red
endfun

augroup myplugin_highlight
  autocmd!
  autocmd ColorScheme * call s:highlight()
augroup end
call s:highlight()

I used a function because we want to run this both on startup and when the ColorScheme autocommand is fired.

It's a bit ugly, but it's the only way.