| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently the new version of LuaJIT changed the consistency with which it
sorted table dictionaries. IIRC lua sorts dictionary keys by memory address, so
it would appear that the reasons tests were previously passing was because of
a differentiation in the implementation of the lua runtime.
Ensure that array fields in the lsp protocol tables are consistently created,
by using ipair when generating arrays for completionItemKind and
symbolItemKind.
For CodeActionKind, the current implementation includes both the keys and the
values in the array. This is incorrect. Ensure that only the values are
included in the array and sort them for consistency.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* First implementation of workspace folders
* Add completion for current directory
* Add tracking of workspace folders
* Add workspace folder listing
* Add checks on adding/removing workspaces
* Add appropriate initialization options
* Add documentation
* Make workspaceFolders available wherever client is
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Breaking Changes:
- Deprecated all `vim.lsp.util.{*diagnostics*}()` functions.
- Instead, all functions must be found in vim.lsp.diagnostic
- For now, they issue a warning ONCE per neovim session. In a
"little while" we will remove them completely.
- `vim.lsp.callbacks` has moved to `vim.lsp.handlers`.
- For a "little while" we will just redirect `vim.lsp.callbacks` to
`vim.lsp.handlers`. However, we will remove this at some point, so
it is recommended that you change all of your references to
`callbacks` into `handlers`.
- This also means that for functions like |vim.lsp.start_client()|
and similar, keyword style arguments have moved from "callbacks"
to "handlers". Once again, these are currently being forward, but
will cease to be forwarded in a "little while".
- Changed the highlight groups for LspDiagnostic highlight as they were
inconsistently named.
- For more information, see |lsp-highlight-diagnostics|
- Changed the sign group names as well, to be consistent with
|lsp-highlight-diagnostics|
General Enhancements:
- Rewrote much of the getting started help document for lsp. It also
provides a much nicer configuration strategy, so as to not recommend
globally overwriting builtin neovim mappings.
LSP Enhancements:
- Introduced the concept of |lsp-handlers| which will allow much better
customization for users without having to copy & paste entire files /
functions / etc.
Diagnostic Enhancements:
- "goto next diagnostic" |vim.lsp.diagnostic.goto_next()|
- "goto prev diagnostic" |vim.lsp.diagnostic.goto_prev()|
- For each of the gotos, auto open diagnostics is available as a
configuration option
- Configurable diagnostic handling:
- See |vim.lsp.diagnostic.on_publish_diagnostics()|
- Delay display until after insert mode
- Configure signs
- Configure virtual text
- Configure underline
- Set the location list with the buffers diagnostics.
- See |vim.lsp.diagnostic.set_loclist()|
- Better performance for getting counts and line diagnostics
- They are now cached on save, to enhance lookups.
- Particularly useful for checking in statusline, etc.
- Actual testing :)
- See ./test/functional/plugin/lsp/diagnostic_spec.lua
- Added `guisp` for underline highlighting
NOTE: "a little while" means enough time to feel like most plugins and
plugin authors have had a chance to refactor their code to use the
updated calls. Then we will remove them completely. There is no need to
keep them, because we don't have any released version of neovim that
exposes these APIs. I'm trying to be nice to people following HEAD :)
Co-authored: [Twitch Chat 2020](https://twitch.tv/teej_dv)
|
|
|
|
|
| |
We support applying all kinds in the spec equivalently and some servers (including dartls) won't send code actions if support for the relevant kinds is not explicitly stated in the client capabilities. Therefore, this PR makes that support explicit.
Also, as we support all CodeActionKinds, we should also mark the server as supporting code actions when it specifies code action kinds. This is also done in this PR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't actually support snippets in core in the way that users would
truly expect. So, by default, we will not say that builtin-lsp has
`snippetSupport`.
To re-enable, users can do the following:
First, get a capabilities dictionary with
`local capabilities = vim.lsp.protocol.make_client_capabilities()`
Then override
`capabilities.textDocument.completion.completionItem.snippetSupport = true`
and then pass those capabilties to the setup function.
```
nvim_lsp.server_name.setup {
...,
capabilities = capabilities,
...,
}
```
See https://github.com/neovim/neovim/issues/12795
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactors how required capabilities are detected and validated, and make
sure requests are only sent to clients that support it (and only fail if
no clients support the provided method).
The validation happens at the buf_request level, because we assume that
if someone is sending the request directly through the client, they know
what they're doing. Also, let unknown methods go through.
This is extracted from #12518 and closes #12755.
Co-authored-by: francisco souza <fsouza@users.noreply.github.com>
|
|
|
|
| |
Most of the lsp.log will be addressed in a separate PR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* LSP: Add support for call hierarchies
* LSP: Add support for call hierarchies
* LSP: Add support for call hierarchies
* LSP: Jump to call location
Jump to the call site instead of jumping to the definition of the
caller/callee.
* LSP: add tests for the call hierarchy callbacks
* Fix linting error
Co-authored-by: Cédric Barreteau <>
|
|
|
|
| |
textDocumentSync.save.includeText only if table. (#12450)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
server before making `request` (#12421)
* Add check for typeDefinition support in vim lsp server
* Check for typeDefinitionProvider in server
* Check for declarationProvider in server
* Add check for client support
* Fix typo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old behavior is: foo(${placeholder: bar, ...)
with lots of random garbage you'd never want inserted.
New behavior is: foo(bar, baz)
(which maybe is good, maybe is bad [depends on user], but definitely better than it was).
-----
* Implement rudimentary snippet parsing
Add support for parsing and discarding snippet tokens from the completion items.
Fixes #11982
* Enable snippet support
* Functional tests for snippet parsing
Add simplified real-world snippet text examples to the completion items
test
* Add a test for nested snippet tokens
* Remove TODO comment
* Return the unmodified item if the format is plain text
* Add a plain text completion item
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add textDocument/codeAction
* Add callback for workspace/executeCommand
* Escape newlines in codeAction titles
* Return empty list in get_line_diagnostics if no buffer diagnostics
* Add stub documentation
* Validate context parameter in code_action
* Add support for edit in CodeAction responses
* Group diagnostics by line in vim.lsp.util.get_line_diagnostics()
* Advertise code action literal support
|
|
|
| |
applyEdit is supported by the built-in client.
|
|
|
| |
use workspace.symbol instead of workspaceSymbol to mimic the lsp spec.
|
|
|
|
|
|
|
|
| |
* lsp: add workspace/symbol
* refactor symbol callback
* set hierarchical symbol support to true
* add documentation and default mapping
Co-authored-by: Hirokazu Hata <h.hata.ai.t@gmail.com>
|
|
|
|
| |
* support LocationLink in callbacks
* announce linkSupport in client capabilities
|
|
|
|
| |
Spec: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_documentSymbol
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- Rename builtin_callbacks to default_callbacks and slightly change its
semantics:
- No longer contains the default implementations. Instead, any
default_callbacks will be used in preference for our .buf methods.
- Add this to the docs.
|
|
Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
|