This is the one script, that is usually causing the most slow down.
Converting it to Vim9 Script should keep vim responsive and the users
happy. Hopefully that works now.
if a color definition is being used, that Vim does not seem to
recognize, instead of erroring out fallback to a hard-coded value of
grey. Otherwise we do have potentially a bad user experience for
throwing too many error messages at the user in very short time, which
may prevent him from doing the actual work (as just happened to me)
Grey should always be defined and it should be rather easy to spot
(I hope). Also just mention for what group this happens.
This should give the user a clue, where and when this happens (so he may
be able to adjust the theme).
the highlighter code tries to convert the RGB colors into appropriate
color codes for the MSDOS palette. Unfortunately, it does not consider
color names and tries to split those into a list of 3 RGB codes. This
failes for names shorter 6 characters, causing a list index out of
bounds error.
Fix this by making sure, that the color code should start with '#' and
in case it does not, assume it is a color name and simple return the
name in that case.
closes#2350
This is needed for Neovim, because an external UI could be attached to
the same neovim server, so it does not make sense to define highlighting
groups with either only the cterm or the guifg attribute set.
So refactor the code slightly got get rid of this variable (and since
this variable is not needed anymore, we can also get rid of the guienter
and OptionSet autocommand).
fixes: #2261
This is actually a work around for a broken installation. the dict p
should always contain the accents key (see `airline#themes#patch()`
function, that adds missing accents). So even if the theme does not
define the accents key, it should always exist.
However, an error while evaluating the statusline is extremely annoying,
so add some safeguards here and skip the following for loop.
related #2043
Groupnames like 'airline_c1_to_airline_x_inactive' still have to be
processed, so do not skip them.
Also for the tabline, '_inactive' groups are not used, so skip them
Replace by a function that retuns the to be executed highlighting string
Should in theory be a bit faster, since the same function does not have
to be called 5 times per highlighting group.
It probably is not much better, but here are some random numbers:
Profiling:
Previously:
count total (s) self (s)
199 0.022973 0.009909 let cmd = printf('hi %s %s %s %s %s %s %s %s', a:group, s:Get(colors, 0, 'guifg=')…
New:
count total (s) self (s)
79 0.010166 0.000862 let cmd = printf('hi %s%s', a:group, s:GetHiCmd(colors))
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')
```
