Make sure, to also check, if the separator groups have already been
defined. Once they are defined initially, they are usually available in
the palette group. So do not redefine them once they have been created
initially.
references #1779
Previously, we only checked for if the name starts with 'airline_c'
But there could as well be highlighting groups starting being called
'airline_b_to_airline_c5', but if buffer 5 is no longer visible in the
current viewport, then we do not need to recreate those groups.
currently, if the matchstr() evaluates to '', it would skip the required
section, because bnr would be evaluated to zero and since there is no
buffer zero, skip that highlighting group.
Make sure, to only skip the highlighting group if the buffer number is
actually > 0
In a long editing session, there could happen to accumulate several
highlighting groups for buffers that might no longer be visible.
Therefore, only re-create the highlighting group for buffers that are
actually displayed in the current tabpage. If not, skip them.
references #1779
previously, it could happen that the same highlighting group was defined
several times, because it was available in several modes within
g:airline#theme[mode]. So the second one would always win.
Therefore, loop through all modes in reverse order and define the group
and remember what group has already been defined. If we happen to have
to re-define the same group, skip it. Since we are traversing the list
in reverse order, this should make sure the last definition wins.
This has the benefit of being more performant and hopefully helps with
e.g. #1779 and similar issues.
This will make sure that the current window will be highlighted as
expected, even if there are no other windows and all highlighting groups
will be correctly re-created as 'inactive'
references #1807
This enables the highlighting caching only when the variable
g:airline_highlighting_cache is set to 1
Should make airline faster and more performant, because we can save a
lot of expensive C core calls. However, when redefining highlighting
groups, it might not correctly reset the cache.
do not access get() function twice. We can assign the result to a
variable and use it a second time. Should speed up the highligther part
of the code by a bit.
Since I was already touching s:Get(), also get rid of the default
parameter, as it always has been the empty string.
The comparison in airline#highlighter#exec() was there to prevent to
call out to too many :hi calls by making sure that the newly to be
defined highlighting group will be actually different from the current
existing one.
However, that did not work, as the returned old highlight
group did never match the newly to be created one, since it
intentionally left the cterm attributes out for the gui and the gui
attributes for the terminal.
Therefore, fix the comparasion and make it compare the actual values
that we have.
This should make vim-airline a bit faster (hopefully!)
previously we only checked, that the group exists, however
if loading a new color scheme, this might lead to the group becoming
cleared. That means it still exists, but the highlighting group would
not show anything. Therefore, also check that the group is not cleared.
closes#1483
previously, it could have been skipped, if the old highlighting
attribute was the same as the current one. However, if the group does
not exist, it should still be defined
closes#1404
If a color value of ['', '', 'NONE', 'NONE', ''] is given as value to
the highlighting group, the resulting group definition would look like
this:
hi Normal ctermfg=NONE ctermbg=NONE
which would result in the highlighting group being cleared (or even no
set at all), therefore check that at least one other value exists and if
not fall back to the highlighting definition of the Normal group.
This seems to be an omission/regression from #afb75adc, where inactive
highlight updating was accidentally removed when fixing another bug.
Solution: Add back the deleted statement. closes#1339
Repro steps:
1. Install some theme that depends on the background color
(Soares/base16.nvim has a bunch)
2. `set background=dark` in your vimrc, and `colorscheme` one of the
aforementioned schemes.
3. Open a split window. Note the colors on the inactive window's airline.
4. `set background=light` manually. note the colors on the inactive
window's airline. Note how they have not updated. (In particular,
airline_c_inactive has updated, but all the other inactive groups
have not.)
5. Enter the inactive window. Exit the inactive window. Observe that the
colors are now correct (showing that it is in fact a problem with the
airline load_theme code, and not with the theme).
It seems strange that the code as written only expects
airline_c_inactive to have styling; perhaps there is some norm that
themes are supposed to handle inactive windows in a particular way? For
the record, my theme dis omething like this:
```
let s:IA1 = s:airlist('similar1', 'similar2')
let s:IA2 = s:airlist('similar1', 'similar2')
let s:IA3 = s:airlist('similar1', 'similar2')
let g:airline#themes#{s:palette}#palette.inactive = airline#themes#generate_color_map(s:IA1, s:IA2, s:IA3)
let g:airline#themes#{s:palette}#palette.inactive.airline_warning = s:airlist('base', 'contrast3')
let g:airline#themes#{s:palette}#palette.inactive.airline_error = s:airlist('base', 'antibase')
```
consider a window with these splits:
,----
| file1
| ---
| file2
| ---
| file1
`----
If the top buffer is the active one and you start modifying this buffer,
this will also reset the highlighting for the inactive buffer2, since
the highlighting group 'airline_c_inactive' is used for both windows
(one having the unmodified buffer 'file2' and one having the modified
'file1').
This lead to the incorrect highlighting of the buffer name of file2.
Airline basically already created different airline_c<bufnr>_inactive
highlighting groups, but unfortunately did not use them.
Therefore, make the builder aware of this and always append the buffer
number to the group 'airline_c' if it is in an inactive window.
2) we need to make sure, the highlighting won't get overwritten, so
make the highlighter aware of this situation as well, by appending the
buffer number to the group name, if it creates the 'inactive' mode
groups and a buffer number has been given.
this fixes#1233
If active buffer is modified, `:AirlineRefresh` apply `normal` highlight
instead of `normal_modified` highlight.
No particular config is requiered to reproduce this bug.
I see this bug with option `g:airline_skip_empty_sections` set.
Add any modification at the active buffer return to normal mode,
**do not save** and wait a few seconds, you can see highlight change to
normal but file is modified.
Without option `g:airline_skip_empty_sections`, add any modification at
the active buffer return to normal mode and type `:AirlineRefresh` you
can see change to bad highlight .
This is required when used with 'Normal' with a transparent background.
Falling back to 1 here results in "red" for "ctermbg"!
I think it's important to keep the 'NONE' color property here, instead
of hardcoding the fallbacks (even if white would be used instead of
red).
Most of them seem to be caused by using :hi statements, although the
highlighting group to be created is exactly the same. Therefore, get the
info from actual definition and only execute :hi when the new group is
actually different.
Also try to avoid to generate :hi statements when the popupmen is
visible. This causes flickers.
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.
