Magnus Groß [Mon, 4 Sep 2023 18:16:43 +0000 (20:16 +0200)]
Fix additionalTextEdits being ignored
Regression was introduced in 6f4fdc7bcc3a1ba041c6196b85b506bd0c207cf0.
The logic was still fine if the LSP server delayed the
additionalTextEdits field, but if we already got it, we ended up
ignoring it.
Fix this by checking for additionalTextEdits outside the delayed-resolve
condition.
Magnus Groß [Mon, 4 Sep 2023 15:50:12 +0000 (17:50 +0200)]
Do not reset cursor after workspaceEdit
The workspace edit may add or delete lines, so resetting it to the last
linenumber and column will very likely not match the last logical line
before the workspaceEdit operation.
For example an action might add an auto-import statement at the top of
the file, effectively adding one line in-between. If we now reset the
cursor, we will end up one logical line before the one where we actually
started at.
This behaviour is automatically fixed if we just don't reset the cursor
at all.
Magnus Groß [Sun, 3 Sep 2023 22:57:59 +0000 (00:57 +0200)]
Add support for CompletionItem commands
When we resolve a completion item with a "completionItem/resolve"
request, the LSP server returns a CompletionItem object [0], which may
contain an optional "command" field. This field describes a command that
must be called **after** inserting the completion.
For example the haskell-language-server may respond with the following
command after autocompleting an unimported function (arguments are left
out for brevity):
Then when we send the matching "workspace/executeCommand" request, the
server will respond with a "workspace/applyEdit" request, that
autoimports the function.
Technically the specification dictates that servers should prefer to set
"additionalTextEdits" for that usecase, but there is still some use for
doing it this way, e.g. haskell-language-server also wants to display an
info message to the user, which doesn't happen with
"additionalTextEdits".
In any case it is important to support the "command" field, as it may
also contain actions unrelated to "additionalTextEdits".
Girish Palya [Thu, 10 Aug 2023 17:26:34 +0000 (19:26 +0200)]
omnifunc documentation popup not throw error
When using Omni completion with other sources of completion items
that do not have 'user_data' dictionary, documentation popup should
not throw error.
I am using my own completion plugin with g:LspOmniFunc and I need
LSP to grab lazy-doc from lsp server. But it should not throw
error when user_data does not contain dictionary.
Add a function to find out if LSP server has replied with completion
matches. This is needed in case of using external completion engines
that expect asynchronous callback. LSP client simply acts as a source
of completion items through omnifunc (g:LspOmniFunc). Before calling
the omnifunc the second time g:LspOmniCompletePending can be checked
to see if LSP server is ready to provide completion items.
Update the client capabilities. Pass buffer number to autocmd handler functions. Send pending file changes to the language server before updating inlay hints and highlights
Magnus Groß [Tue, 11 Jul 2023 16:56:19 +0000 (18:56 +0200)]
Never show diagnostics when they are disabled
A regression was introduced in 6e4ba228eaa0770470060d8d47a360bd05a04ee5
that causes diagnostics to be displayed on buffer reload, even when the
user disabled them.
Fix this by moving the option check directly to DiagsRefresh.
Add the ":LspDiag" command and add sub-commands for the various Lsp
diagnostic functionality. Update the test scripts to use the new set of
commands. Add support for dynamically changing the value of the
diagnostic options. Remove the ":LspDiagHighlightEnable" and the
":LspDiagHighlightDisable" commands (these are replaced by the ":LspDiag
highlight" command)
Yegappan Lakshmanan [Thu, 29 Jun 2023 04:44:00 +0000 (21:44 -0700)]
Add an option (showDiagWithSign) to enable/disable placing signs on lines with diagnostics. Add separate virtual text highlight groups for each type of diagnostic
Girish Palya [Sun, 25 Jun 2023 11:26:37 +0000 (13:26 +0200)]
Make buffer completion responsive for large files
Since buffer completion processes the current buffer everytime user
types something, it will degrade the experience for large files.
This change adds a timeout to buffer completor function. Processing
current buffer is cut short when timeout is exceeded. Setting
timeout to 0 will revert back to existing behaviour.
Default is set to 100 ms, good for scanning 6000 lines on M1 macbook.
It is possible to get fancy by scanning locality of cursor first
but such complication may not be worth the complexity.
Tested on >20k line files (I have to open these large C files
filled with hw specs occasionally).
M autoload/lsp/completion.vim
M autoload/lsp/options.vim
M doc/lsp.txt