With help from Karl Lervag's suggestion on how to reliably tell when the
above mentioned conditions are the case for the current buffer
Checked to work with other filetypes that use the wordcount in
vim-airline, and these seem to work as before.
Also checked that if two of these filetypes (one TeX and the other
another type, such as markdown) the two coexist peacefully, with TeX
using Karl's wordcount function, and the other using the (I assume)
native wordcount?
Fixed comment wording
Hello.
This PR should solve my pain as CoC user, that CoC status takes too much space in the C section, right after the file path.
It looks like a waste of space on splitscreen or a small screen.
So I added an option to set
g:airline#extensions#coc#show_coc_status = 0
and the status will be hidden.
By default it works like usual.
Displays whether you have the ruby formatter enabled or not for the
session you are in.
Enable with:
let g:airline#extensions#rufo#enabled = 1
Configure with:
let g:airline#extensions#rufo#symbol = '💎'
vim-airline does not use actually use the `g:coc_stl_format` variable
and it also doesn't seem to be used by coc itself. So let's just remove
this code.
closes#2437
Use TabNew/TabClosed for the "autoshow" event when tabline is used only
for tabs (show_buffers==0). This fixes case of visible tabline when
tab_min_count == 2 and user executes ':tabonly' command - the tabline
should disappear but there is no TabEnter event triggered in this case.
Closes#2389
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.
Ignore 'wildignore' and 'suffixes' when globbing for themes and extensions.
This can be a problem when you have a wildignore containing *.vim.
closes#2375
Several extensions trigger custom actions. Make sure, those actions are
only performed, if airline is actually active and not temporarily
disabled using e.g. :AirlineToggle
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).
Indelog