The right way to override any highlighting if you don't want to edit the colorscheme file directly

colorscheme-override.vim

" Suppose you have weird taste and you *absolutely* want: * your visual
" selection to always have a green background and black foreground, * your
" active statusline to always have a white background and red foreground, * your
" very own deep blue background.
"
" Your first reflex is probably to put those lines somewhere in your 'vimrc':

highlight Visual cterm=NONE ctermbg=76 ctermfg=16 gui=NONE guibg=#5fd700 guifg=#000000
highlight StatusLine cterm=NONE ctermbg=231 ctermfg=160 gui=NONE guibg=#ffffff guifg=#d70000
highlight Normal cterm=NONE ctermbg=17 gui=NONE guibg=#00005f
highlight NonText cterm=NONE ctermbg=17 gui=NONE guibg=#00005f

" But it quickly appears that those lines have no effect if you source
" a colorscheme later in your 'vimrc' so you move them below:

colorscheme foobar
highlight Visual cterm=NONE ctermbg=76 ctermfg=16 gui=NONE guibg=#5fd700 guifg=#000000
highlight StatusLine cterm=NONE ctermbg=231 ctermfg=160 gui=NONE guibg=#ffffff guifg=#d70000
highlight Normal cterm=NONE ctermbg=17 gui=NONE guibg=#00005f
highlight NonText cterm=NONE ctermbg=17 gui=NONE guibg=#00005f

" which gives the desired outcome. Everything is fine. In principle.
"
" But you like to try new colorschemes, or you prefer to have different
" colorschemes for different filetypes or time of the day and your overrides
" don't carry over when you change your colorscheme.
"
" This is because colorschemes usually reset all highlighting, including your
" own, when they are sourced.
"
" The solution is to override the desired highlights in an autocommand that's
" executed whenever a colorscheme is sourced:

augroup MyColors
	autocmd!
	autocmd ColorScheme * highlight Visual cterm=NONE ctermbg=76 ctermfg=16 gui=NONE guibg=#5fd700 guifg=#000000
			    \ highlight StatusLine cterm=NONE ctermbg=231 ctermfg=160 gui=NONE guibg=#ffffff guifg=#d70000
			    \ highlight Normal cterm=NONE ctermbg=17 gui=NONE guibg=#00005f
			    \ highlight NonText cterm=NONE ctermbg=17 gui=NONE guibg=#00005f
augroup END

Thank you

"nested" is precisely what I didn't know I was searching for. Thanks!

Thank you! This was driving me crazy

Can you say more about nesting? I'm not sure I understand why it's needed here. The Vim documentation says that it's needed when an autocmd calls :e or :w.

@openjck, by default, autocommands don't trigger other autocommands. In the classic example I use in the "article", an autocommand is set to :source $MYVIMRC automatically when you write it. The problem, here, is that you are very likely to have a line like this one somewhere in your vimrc:

colorscheme whatever

which, when it is executed as part of the re-sourcing of your vimrc, won't trigger the autocommand described in the article because of that "no nesting" rule. Adding the nested keyword allows autocommands to trigger other autocommands and thus our ColorScheme autocommand to be triggered by the BufWritePost autocommand.

@romainl That makes sense. Thank you for the detailed response!

Thank you!

Thanks

Well, it works!
My highlight settings always override by other unknown settings, which makes me annoyed. Thanks very much!

I find this solution shall fail to tune the TabLine colors when vim-airline is at play. Without offloading vim-airline altogether, specifying hi! link airline_tabfill VertSplit (or other highlight groups) serves as a variable way to tune the color for the TabLine highlight group.

@llinfeng I would see that as a sign of bad design on vim-airline's side, not as a failure of this method.

@romainl, I enjoyed reading about catching the ColorScheme triggering condition and reloading customized highlight groups when the color scheme changes. Yet, as with the TabLine highlight group (or the airline_tabfill from vim-airline), there are other cases where highlight groups are administrated by a third-party plugin. I also agree with your comment on the "bad design" aspect.

thank you 🙏

Thanks!!!

Thanks!

It seems

[...]
autocmd BufWritePost $MYVIMRC nested source $MYVIMRC
[...]

will add source $MYVIMRC to this autocmd each time this is sourced. This has exponential growth so it will get very slow very quickly.

I think it's better to do:

autocmd! BufWritePost $MYVIMRC
autocmd BufWritePost $MYVIMRC nested source $MYVIMRC

@tornaria, this gist is not really about autocommands or about that "trick" for re-sourcing one's vimrc (that I personally find silly) so I wrote it assuming the reader already handles autocommands properly in their vimrc, hence the [...]. The proper way would be:

augroup somename
autocmd!
autocmd BufWritePost $MYVIMRC nested source $MYVIMRC
augroup END

If you cannot control the order of definition of your autocmd, and a colorscheme has already been loaded,
you can exec :doautocmd Colorscheme to retrigger the event.

I am using this piece of Lua code in Neovim, but should be possible with Vim as well (not sure about the proper way to do it with Vimscript):

        -- If colorscheme has already been loaded, trigger autocmds again
        if vim.g.colors_name == 'your-current-colorscheme' then
          vim.cmd('doautocmd ColorScheme')
        end

@kdarkhan, your snippet is sadly useless for Vim users. Consider posting an alternative that works in Vim. Also, consider explaining how your scenario could happen.

Sure. I spent some time investigating this with vimscript. It will look like this

if exists("colors_name")
  doautocmd ColorScheme
endif

This is useful if you cannot ensure that your autocmd Colorscheme definitions are executed before colorscheme {your-colorscheme} is executed. In my case, I am trying to modularize my config, and there is a plugin which adds some custom highlights using autocmd Colorscheme.

I am keeping each plugin configuration independent from each other to make it more maintainable. That way, for example, if I decide to remove this custom highlight plugin, I will do the change only in a single place.

OK, thanks for your input. You are free to do what you want with your config but FWIW, modularisation of one's Vim/Neovim is rarely worthwhile. The fact that you end up in a situation that requires such a hack is kind of telling.

Yeah of course, just wanted to share, maybe somebody will find this useful.

Thanks good approach ! 🙏

Vimscript equivalent for @kdarkhan's Lua snippet:

if g:colors_name == 'your-current-colorscheme'
    doautocmd ColorScheme
endif

Just a note, even the autocommand may not work right on colorschemes like this one that do async stuff. For this one the quick way I solved it was to resort to forking it, editing the stuff that it messes up, and just pointing my plugin loader at my fork.

thanks!

How does this work if I don't set any colorscheme? My use the colorscheme of my terminal.

@xiaoqixian, if you don't explicitly set a colorscheme, say with colorscheme malotru, then Vim uses its default colorscheme called default but the ColorScheme event is not triggered. Since this gist is based on autocommands and events, it can't work if the ColorScheme event is not triggered.

The solution is to set the default colorscheme explicitly:

colorscheme default

Thank you very much