Currently, for large number of diagnostics, the delay in populating
loclist may be sufficient for a user to switch to another window,
resulting in the loclist being populated on the wrong window.
In the documentation for `vim.lsp.util.open_floating_preview`
the opts table keys were prefixed with `--` instead of `---`,
preventing capture by docgen.
This pr allows the user to specify whether `lsp.utils.open_floating_preview`
is focusable via the `opts` parameter. Defaults to true.
It can be configured by setting the focusable key inside opts parameter:
```lua
vim.lsp.util.open_floating_preview(contents, syntax, {focusable = false})
```
handlers passed to `lsp_buf_request` weren't called if the server
responded with an error that looks like this:
"decoded", {
error = {
code = -32601,
message = "No delegateCommandHandler for foo"
},
id = 5,
jsonrpc = "2.0"
}
An example where that happens is both eclipse.jdt.ls and the
haskell-language-server when invoking a command that doesn't exist:
:lua vim.lsp.buf_request(
0,
'workspace/executeCommand',
{ command = 'foo' },
function(err, _, res)
print(vim.inspect(err), vim.inspect(res))
end
)
fix: fancy_floating_markdown: syn region must include keepend to make sure syntax regions are applied correctly. Fixes#14594
feat: fancy_floating_markdown: handle <pre></pre> code blocks as a markdown code block with plaintext
fix: possible nil check for markdown code blocks till end of buffer
refactor: only one check is needed to see if stripped[h.finish +1] is valid
fix(lsp): dont't set doc ownsyntax, since it breaks contained syntaxes. Set regions for the markdown blocks intsead
fix: apply markdown formatting for code blocks without a language
fix: use markdownCodeBlock when no language was set in a code block
Unfortunately, there are some subtle bugs in the smarter tagstack changes,
so we'll revert them for now and try to come up with a better approach.
One of the added tests, adds current position to jumplist before jumping,
is valuable though and changed to still work after reverting the other two
commits.
Closes#14571
Some servers might respond to `workspace/executeCommand` requests with a
boolean result and that could be `false`.
A `false` result should be allowed and not trigger the `on_error`
handler:
-- Invalid server message
on_error(client_errors.INVALID_SERVER_MESSAGE, decoded)
Concrete example where this occurred is with eclipse.jdt.ls:
vim.lsp.buf_request(
0,
'workspace/executeCommand',
{
command = 'java.project.isTestFile',
arguments = { vim.uri_from_bufnr(0), },
},
function(err, _, resp)
print(vim.inspect(err), vim.inspect(resp))
end
)
This commit prevents two things regarding the tagstack and jumping to
locations:
- Pushing the same item twice in a row
- Pushing an item where the destination is the same as the source
Both prevent having to press CTRL-T additional times just to pop items
that don't make the cursor move.
Allow to sort diagnostics (and thus signs and virtual text) by severity, so that
the most important message is shown first.
vim.lsp.handlers['textDocument/publishDiagnostics'] = vim.lsp.with(
vim.lsp.diagnostic.on_publish_diagnostics, {
severity_sort = true,
}
)
Fixes https://github.com/neovim/neovim/issues/13929
If vim.lsp.log is loaded the second time,
the vim.log.levels will be modified with additional
entries from 0-5.
This will cause the require to fail as level:lower does
not exists on numbered value.
There were a couple of reports of "Buffer X newer than edits" problems.
We first assumed that it is incorrect for a server to send 0 as a
version - and stated that they should send a `null` instead, given that
in the specification the `textDocument` of a `TextDocumentEdit` is a
`OptionalVersionedTextDocumentIdentifier`.
But it turns out that this was a change in 3.16, and in 3.15 and earlier
versions of the specification it was a `VersionedTextDocumentIdentifier`
and language servers didn't have a better option than sending `0` if
they don't keep track of the version numbers.
So this changes the version check to always accept `0` values.
See
- https://github.com/neovim/neovim/issues/12970
- https://github.com/neovim/neovim/issues/14256
- https://github.com/haskell/haskell-language-server/pull/1727
