Design goals/requirements:
- Default configuration of a server can be distributed across multiple sources.
- And via RTP discovery.
- Default configuration can be specified for all servers.
- Configuration _can_ be project specific.
Solution:
- Two new API's:
- `vim.lsp.config(name, cfg)`:
- Used to define default configurations for servers of name.
- Can be used like a table or called as a function.
- Use `vim.lsp.confg('*', cfg)` to specify default config for all
servers.
- `vim.lsp.enable(name)`
- Used to enable servers of name. Uses configuration defined
via `vim.lsp.config()`.
Using the "supports_method" function with a client capability inside of
an LspAttach autocommand is the preferred method to do this, so we
should be showing users how to do it.
* refactor(shared): extract `vim._list_insert` and `vim._list_remove`
* feat(lsp): add `vim.lsp.foldexpr()`
* docs(lsp): add a todo for state management
* feat(lsp): add `vim.lsp.folding_range.foldclose()`
* feat(lsp): schedule `foldclose()` if the buffer is not up-to-date
* feat(lsp): add `vim.lsp.foldtext()`
* feat(lsp): support multiple folding range providers
* refactor(lsp): expose all folding related functions under `vim.lsp.*`
* perf(lsp): add `lsp.MultiHandler` for do `foldupdate()` only once
**Problem:** The `context` parameter for `references()` is just typed as
a table, which is unhelpful.
**Solution:** Properly type it as an `lsp.ReferenceContext`!
Problem:
LSP spec uses the term "position encoding" where we say "offset encoding".
Solution:
- Rename it everywhere except `vim.lsp.Client.offset_encoding` (which would be breaking).
- Mention "position encoding" in the documentation for `vim.lsp.Client.offset_encoding`.
Problem:
Since [version 3.17](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocuments),
LSP supports specifying the position encoding (aka offset encoding) supported by
the client through `positionEncoding`. Since #31209, Nvim fully supports
`utf-8`, `utf-16`, and `utf-32` encodings.
Previously, nvim assumed all clients for a buffer had the same
`offset_encoding`, so:
* Nvim provides `vim.lsp._get_offset_encoding()` to get `offset_encoding`, but
this function is incorrect because `offset_encoding` is per-client, not
per-buffer.
* Based on the strategy of `vim.lsp._get_offset_encoding()`,
`vim.lsp.util.make_position_params()`, `vim.lsp.util.make_range_params()`, and
`vim.lsp.util.make_given_range_params()` do not require the caller to pass
`offset_encoding`, which is invalid.
* https://github.com/neovim/neovim/issues/25272
Solution:
* Mark `vim.lsp._get_offset_encoding()` as `@deprecated`.
* Change the type annotations of `vim.lsp.util.make_position_params()`,
`vim.lsp.util.make_range_params()`, `vim.lsp.util.make_given_range_params()`
to require the `offset_encoding` param.
Problem:
Capability register logic is spread across 3 files.
Solution:
- Consolidate (and simplify) logic into the client.
- Teach client.supports_method about resolve methods
**Problem:** Despite the LSP providing the option for language servers
to specify a range with a hover response (for highlighting), Neovim does
not give the option to highlight this range.
**Solution:** Add an option to `buf.hover()` which causes this range to
be highlighted.
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
- Partition the handlers in vim.lsp.handlers as:
- client to server response handlers (RCS)
- server to client request handlers (RSC)
- server to client notification handlers (NSC)
Note use string indexes instead of protocol.methods for improved
typing in LuaLS (tip: use hover on RCS, RSC or NSC).
Co-authored-by: David Pedersen <limero@me.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Leo Schlosser <Leo.Schlosser@Student.HTW-Berlin.de>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
- `vim.highlight` module does not follow `:help dev-name-common`, which
documents the name for "highlight" as "hl".
- Shorter names are usually preferred.
Solution:
Rename `vim.highlight` to `vim.hl`.
This is not a breaking change until 2.0 (or maybe never).
The current LspAttach example shows setting options which are already
set by default. We should expect that users are going to copy-paste
these examples, so we shouldn't use examples that are superfluous and
unnecessary.
An implication of this current approach is that `NVIM_API_LEVEL` should be
bumped when a new Lua function is added.
TODO(future): add a lint check which requires `@since` on all new functions.
ref #25416
Some composite/compound types even as basic as `(string|number)[]` are
not currently supported by the luacats LPEG grammar used by gen_vimdoc.
It would be parsed & rendered as just `string|number`.
Changeset adds better support for these types.
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
Updated the `rpc.connect` function to support connecting to LSP servers
using hostnames, not just IP addresses. This change includes updates to
the documentation and additional test cases to verify the new
functionality.
- Modified `connect` function to resolve hostnames.
- Updated documentation to reflect the change.
- Added test case for connecting using hostname.
Added a TCP echo server utility function to the LSP test suite. This
server echoes the first message it receives and is used in tests to
verify LSP server connections via both IP address and hostname.
Refactored existing tests to use the new utility function.
Problem: Some items of completion results include function signatures that can
cause the pum to be very long when a function has many params, because pum
scales with the longest word/abbr.
Solution: add custom covert function that can customise abbr to remove params.
Auto-completion and auto-formatting are common (though certainly not
universal) features that many users want. We can document how to
accomplish this in lsp-quickstart so that users that do want these
features can easily find examples of how to configure them.
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
Co-authored-by: Jose Pedro Oliveira <jose.p.oliveira.oss@gmail.com>
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
