Ref: https://github.com/blueyed/vim-colors-solarized/commit/92f2f994
This also defines 'g' (gui) colors, which might not be necessary and
cause unnecessary overhead (at least it caused an error when given an
invalid color (RGB without hash symbol), but was added for completeness.
- darken green background of INSERT (to match original)
- restore orange modified highlight
- unify 2nd sections, deduplicate 3rd sections
- make sides of inactive bar brighter for better readability
Using the "CursorLine" highlight style was not a good idea for the status line,
because it conflicts when the cursor line is next to the status line of an
inactive window.
Fortunately, the tabline extension allows for specific color customization.
This explicitly defines a color for a selected tab and a selected buffer.
Currently, vim-airline uses hard-coded '\s$' to check for trailing
whitespace. However you might want to check for different values.
Therefore, set the variable
g:airline#extensions#whitespace#trailing_regexp to the required regexp
value.
closes#663
1) allow for custom formatting of the output of the wordcount formatter
This allows for formatting numbers correctly e.g. 1,042 in English
locale and 1.042 in German locale.
2) cache values, so that no on every cursor move the wordcount needs to
be recalculated.
this issue fixes#758
The problem was, that a given color list ['','',0,'',''] was given to
the airline#highlighter#exec() function. This resulted in the following
comparison:
if (get(colors,2,'') != '') ? 'ctermfg='.colors[2] : ''
which, since echo 0 != '' returns falls will return a single:
:hi group
and no color codes given and therefore, Vim would output the
current highlighting group.
Use isnot# as comparison to fix this issue.
This fixes#511
It allows the virtualenv plugin to call back and tell the airline plugin
to update the statusline. Therefore, the new function
airline#extensions#virtualenv#update() is provided. However, to properly
fix this issue, the virtualenv plugin needs to call this function.
Second, depending on $VIRTUAL_ENV is not safe, since the virtualenv
plugin might define it itsself when calling :VirtualEnvActivate
Therefore skip this test and just test for existance of he
:VirtualEnvList command.
