Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
created December 13, 2001 · complexity intermediate · author Cory T. Echols · version 6.0
Suppose there's a colorscheme that you're pretty fond of, but hate one or two particular aspects about. For example, I love the "blue" colorscheme that ships with vim, but I find it's colors for the non-active status line to be unreadable. Here's how to create a colorscheme which extends "blue" without copying it to a new file and editing it.
In my ~/.vim/colors, I created a "my-blue.vim" file with these contents:
"these lines are suggested to be at the top of every colorscheme hi clear if exists("syntax_on") syntax reset endif "Load the 'base' colorscheme - the one you want to alter runtime colors/blue.vim "Override the name of the base colorscheme with the name of this custom one let g:colors_name = "my-blue" "Clear the colors for any items that you don't like hi clear StatusLine hi clear StatusLineNC "Set up your new & improved colors hi StatusLine guifg=black guibg=white hi StatusLineNC guifg=LightCyan guibg=blue gui=bold
That's all there is to it.
If you want to create rules for a color terminal instead of a GUI, you would obviously use ctermfg, ctermbg, and cterm instead of guifg, guibg, and gui. If the only thing you don't like about a colorscheme is the lack of cterm support, then you can eliminate the "hi clear" statements and just apply the cterm statements. They will add or change any existing cterm color without modifying the gui definitions.
If the color scheme does not define colors for a cterm at all, then it is probably easier to use the CSApprox plugin to allow you to just use the GUI colorscheme directly, instead of trying to come up with replacement colors on your own.