Because Tlist_Get_Filenames() only exists within yegappan/taglist,
TlistUpdate was being envoked on every call when using other taglist
versions.(Like vim-scripts/taglist.) This caused visual artifacts and
slowdowns.
We now check for a function from both taglist variants to see if either
one has been loaded.
Avoid the error `Unknown function: taglist#Tlist_Get_Tagname_By_Line`
when using the old tag tlist plugin in a different way.
this means, we have to revert 5841039679
since exists() does not handle autoloaded functions correctly.
We can only check it, after we have used the taglist plugin, so that the
autoloading has happened. That means, move the exists() call after the
`:TListUpdate` call which will correctly autoload taglist and then
exists() can check for the existence of the
`taglist#Tlist_Get_Tagname_By_Line()` function correctly.
closes: #2463
So 47bf6b1716 added support for
yegappan/taglist plugin, but unfortunately the old (deprecated)
vim-scripts/taglist.vim repo still exists and this one throws an error
when trying to access taglist#Tlist_Get_Tagname_By_Line
So check, that this function is defined before trying to load the
extension
While Commit e542f5e introduced a nice little feature for TeX files to
accurately count words, this unfortunately has the drawback of being
possibly slow, especially since the statusline is often re-evaluated.
Therefore disable this feature by default. You can enable it using:
:let g:airline#extensions#vimtex#wordcount = 1
fixes#2461
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).
coc.nvim exposes the name of the function the cursor is currently in
through b:coc_current_function.
For this to work, the key coc.preferences.currentFunctionSymbolAutoUpdate
must be set to 'true' in the coc config.
The value is only updated on CursorHold, so the value may not always be
accurate when moving around.
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
Fix NUL file created when opening a .po file.
Using -o NUL actually creates a file called NUL in the current
directory. Using /NUL doesn't create one in C:\ (the drive the file is
located on) or any visible drive.
Despite msgfmt being able to create the file NUL (which isn't supposed
to be allowed), it's difficult to delete NUL (windows explorer can't
handle it but WSL's unix rm can remove it).
Test
Open po file and see the same warnings as before, but no NUL file
created.
Using msgfmt.exe provided by git (installed via scoop).
The current implementation of tagbar does not allow for setting the
search-method in the `tagbar#currenttag` function. In
https://github.com/preservim/tagbar/pull/696, tagbar implemented this,
which has three options: nearest, neartest-stl, and scoped-stl.
The reason for adding this - for me, at least - is to use the scoped-stl
option, so that the statusline will display the proper function when
there are nested functions. (Otherwise, once you go past a nested
function, tagbar#currenttag still returns the nested function rather
than the function it was nested in.)
Check for differing neovim versions with different APIs for LSP.
Fixes#2324
Consists of two tests:
1. Before extension load, test if this is neovim and whether this neovim
supports LSP
2. When getting diagnostic counts, test whether a language server is
attached to the current buffer
closes#2324
Note: seems like one needs to call v:lua.vim.lsp.buf_get_clients() and
even then some older neovims do not understand that. So wrap it around
an exists() call and hope this works for all neovims.
nvimlsp removed the :LspInstallInfo command. So instead check explicitly
for neovim for enabling the nvimlsp extension.
In the extension itself check that at least one LSP is attached to the
buffer before returning warning and error messages.
closes#2323
Fix: a literal '0' appears after filename on older versions of vim-lsp.
0c8164b1b3 added support for showing lsp
progress, but didn't always explicitly return a value. Vim uses 0 as a
return value when none are supplied, so when used with an older version
of vim-lsp that doesn't have the progress feature a 0 appeared in the
statusline.
Included `.vue` extension to jsformatter for supporting Vue.js files. Vue files follows the same path resolution as js files: https://vue-loader.vuejs.org/spec.html#src-imports
Case sensitive comparison for jsformatter
closes#2314#2154
Add a leading space before the searchcount statistics. Note, that this
uses a non-breaking space, because it looks like Vim is stripping aways
leading space characters (see vim/vim#1431)
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
