I have been experimenting with colours for my statusline recently and I put the plugin file in the bundle directory. I use pathogen which loads everything up from that directory. But, Even though the status line plugin is getting sourced, the colours are not appearing.

When I manually source the file from GVim it adds all the colours but its not doing this automatically when the plugin loads up. This is happening only in Gvim. Vim in Powershell and Cygwin that use the same plugin show the statusline colours properly when they start up.

What could be the reason for this and what can I change in the plugin to get it working in gvim?

Edit: I have the following line for the colorscheme in my gvimrc, when I remove it from gvimrc and add it in vimrc, everything works fine.

colorscheme solarized

Github link for the plugin's source - Vim Streamline

  • You mean you're using #HighlightName# inside statusline correct? Could you add the code of the plugin you are writing? People may be able to replicate the issue.
    – grochmal
    Aug 6, 2016 at 22:46
  • @grochmal Yes. I have several highlight groups defined in the plugin and I am using them for the colors. I've added the github link to the plugin. Aug 7, 2016 at 5:28
  • What does :highlight User1 say? Aug 8, 2016 at 2:09
  • I have added hi User1 ctermfg=blue ctermbg=yellow guifg=blue guibg=yellow in the plugin file but when I run it in gvim it says User1 xxx cleared. Looks like something is removing the previously set highlights. Aug 8, 2016 at 4:45
  • Ok, I finally found a way to make it work. I realized I have colorscheme solarized in my gvimrc and moved it to vimrc and everything's fine after that. Apparently solarized is overwriting all the highlight groups that I have defined in my plugin but I am not really sure why that is not happening with vimrc. What is the order of sourcing the files? Aug 8, 2016 at 6:49

1 Answer 1


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

augroup myplugin_highlight
  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.

  • Thank you for explaining. Its working properly now. I always thought gvimrc would be sourced right after vimrc. And infact when I run :scriptnames, I see gvimrc before any other plugins from the bundle directory. Aug 8, 2016 at 9:00
  • @DurgaSwaroop Hm, well, this is what the docs say unless I misunderstood. Either way, you want to use the autocmd scheme, especially in plugins. Aug 8, 2016 at 9:30
  • @Carpetsmoker, what's the reason for the augroup? Is it necessary? Feb 11, 2017 at 14:44
  • @StephenRasku It's not strictly necessary, but it is useful. See: Why should I use augroup? (be sure to read all three answers, since they provide three different reasons). Feb 11, 2017 at 14:45
  • @Carpetsmoker, thanks for the answer. That was quick! Feb 11, 2017 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.