gVim: remove syntax highlighting groups

7
votes

Original title was «Language-specific color-schemes prevent simpler ones from coloring certain language-specific tags»

I'm using gVim 7.3 (on Ubuntu 12.04 Arch x86/64, for that matters).

UPDATE (2013-03-02):

I think I can finally express exactly what I mean (I still couldn't find the correct command, assuming it even exists!). Basically this is the flow:

  1. start session with a small footprint colorscheme which defines few basic groups (like Statement, Comment, Function);
  2. switch to a "larger" colorscheme (like Solarized or Jellybeans), which defines more specific groups (like vimCommand, hsImport or rubyBeginEnd). These more specific groups override basic ones;
  3. switch back to a "smaller" colorscheme (one which doesn't define specific groups).

The result is that the session is cluttered with "homeless" group that obscure the basic ones and prevent some words to be highlighted at all. These homeless groups look like the following:

INPUT :hi vimCommandEnter
OUTPUT vimCommand xxx cleared

By the way something similar is experienced and issued in the Solarized's github issue tracker → Vim colorscheme leaves a wake of destruction when switching away

UPDATE (2012-11-25):

Probably, a good solution would be clearing the current session's "highlight" variables (I'm not talking about variables like smartindent, encoding, number, but rather about variables like Statement, Comment rubyClass, xmlTag, i.e. the ones defined by commands like hi link ..., highlight ..., etc.).
If anyone could explain how it is stored in memory, it could maybe help me figuring out how to clean it away (I've tried saving a session through :mksession mysession.vim and then looking into it, but there's no trace of any syntax highlighting variable).

Also, and this is just a vague supposition, it seems that the reason why :hi clear doesn't clean up the highlight groups is that the "leftovers" were defined through an indirect definition (e.g. hi link).

Original:

When my default colorscheme (a modified version of blueshift) is loaded every tag that should be highlighted is correctly coloured.
enter image description here

During the session, I switch to jellybeans colorscheme (:colo jellybeans), which has many more options than my default color-scheme:
jellybeans.vim

If I switch again to my default colorscheme (:colo blueshifted), some highlighting is disabled:
enter image description here

It seems that at the beginning of the session if I use a color-scheme that doesn't specify the behaviour for some language-specific tags, those tags are auto-coloured using some existing colors.

I know that jellybeans's language-specific tags remain in the "cache" and are the responsible for disabling the auto-coloring feature, because if I switch between colorschemes that don't have language-specific tags (without ever using jellybeans), the auto-coloring isn't ruined.

The same happens with other color-schemes (for example railscasts.vim uses HTML-specific coloring). I know I can solve the issue by adding the missing tags in the less-specific color-scheme, but I'm looking for a more general solution.

The Questions

  • what can I do to avoid that these auto-setting colors (used when the first color-scheme is loaded) are disabled when a less detailed color-scheme is loaded after a more-detailed color-scheme?

  • Can I clean up the session cache (i.e. remove the specific tags used by jellybeans.vim from the "session cache") when I change color-scheme?

My attempts These are the commands I used in various combination, to no avail:

:syntax off
:syntax clear
:hi clear
:syntax reset

The only thing that works (obviously!) is redefining by hand the hi link commands missing in the "simple" colorscheme. But of course this is no different by using the other colorscheme (like Solarized) with changed colors. Of course this is not a solution to the question "How do you remove highlighting groups leftovers?".

1
syntax-highlightingvimcolor-schemevim-syntax-highlighting
hi clear should take care of it but I suspect it is has to do with set background=light vs set background=dark. Does it happen when you switch to and from a light colorscheme? – romainl
@romainl The problem still happens even after using hi clear. I tried setting a dark (non-detailed) color-scheme as default, and switching with jellybeans, but the auto-coloring is ruined in this case too. – Nadir Sampaoli

1 Answers

5
votes

I may be a bit late :-) but I believe I solved this problem. Below is a quote of the post I made on the Solarized issue tracker on GitHub.

Hi all,

Sorry to barge in here a year after the last comment and suggest to close an issue on a project I'm not involved in (although I am a happy user :-) however I believe that: 1. this is caused by a bug in Vim and 2. I've found a fairly elegant workaround. So I suppose this issue can be closed?

Several years ago I wrote a color scheme switcher plug-in for Vim but never published it. Shortly after creating my plug-in I noticed the behavior described in this issue and became annoyed by it, convinced that it was a bug in Vim. I even went so far as to try and fix the issue inside the Vim C code but that was a bit too much for me :-]. Back then I had never heard of Solarized; I encountered the problem with a couple of other color schemes (including my own).

Today I decided to publish the color scheme switcher plug-in (see xolox/vim-colorscheme-switcher) and before I published the plug-in I decided to take another stab at fixing the problem described here. I tried all sorts of nasty hacks but ended up with a fairly elegant workaround that doesn't seem too fragile. The readme / homepage contains an explanation of how it works (I'm quoting it below for your convenience).

The way Vim color schemes are written isn’t really compatible with the idea of quickly switching between lots of color schemes. In my opinion this is an ugly implementation detail of how Vim works internally, in other words I think it’s a bug that should be fixed… Here are some references that explain the problem in some detail:

Since this behavior hinders cycling through color schemes, the color scheme switcher plug-in includes a workaround that should hide the problem:

  1. At startup a dictionary is created which will be used to remember links between highlighting groups.
  2. Before and after loading a color scheme, the color scheme switcher plug-in runs the :highlight command without any arguments to find links between highlighting groups. Each link that is found is added to the dictionary. Existing entries are updated. This is done by calling xolox#colorscheme_switcher#find_links().
  3. After loading a color scheme, the color scheme switcher plug-in runs the :highlight command without any arguments to find highlighting groups in the state ‘cleared’. For each of these groups, if they were previously linked, the link is restored. This is done by calling xolox#colorscheme_switcher#restore_links().

Probably this solution is still not perfect, but it’s a lot better than the behavior out of the box: Before I implemented the steps above, when I would cycle through my color schemes, Vim would eventually end up with black text on a white background and nothing else! With the steps above, I can cycle as many times as I want and all of the color schemes I’ve checked so far look fine.

I would love feedback on the (technique used by the) color scheme switcher; I hope it works as well for you as it does for me. I tested it in Vim 7.3 on Linux (GTK) and in MacVim 7.3.