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)
