refactor!: `vim.lsp.inlay_hint()` -> `vim.lsp.inlay_hint.enable()`
Problem:
The LSP specification allows inlay hints to include tooltips, clickable
label parts, and code actions; but Neovim provides no API to query for
these.
Solution:
Add minimal viable extension point from which plugins can query for
inlay hints in a range, in order to build functionality on top of.
Possible Next Steps
---
- Add `virt_text_idx` field to `vim.fn.getmousepos()` return value, for
usage in mappings of `<LeftMouse>`, `<C-LeftMouse>`, etc
The class `lsp.Client` has a public member `server_capabilities`,
which is assumed to be non-nil once initialized, as documented in
`:help vim.lsp.client`. Due to the possibility that it may be nil
before initialization, `lsp.Client` was not having a proper lua type
annotations on the field `server_capabilities`.
Instead of having a nil `server_capabilities` until initialized in
the RPC response callback, we can have an initial value of empty table.
This CHANGES the behavior of the `server_capabilities` field in a way
that it is no longer `nil` until initialization. Note that, as
already documented, `server_capabilities` should never be nil when
it is once initialized and thus ready to be used in user configs.
This fixes the issue where the LspNotify handlers for inlay_hint /
diagnostics would end up refreshing all attached clients.
The handler would call util._refresh, which called
vim.lsp.buf_request, which calls the method on all attached clients.
Now util._refresh takes an optional client_id parameter, which is used
to specify a specific client to update.
This commit also fixes util._refresh's handling of the `only_visible`
flag. Previously if `only_visible` was false, two requests would be made
to the server: one for the visible region, and one for the entire file.
Co-authored-by: Stanislav Asunkin <1353637+stasjok@users.noreply.github.com>
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
Problem:
With tsserver LSP, omni completion after "." inserts an extra "."
Solution:
Apply adjust_start_col() regardless of `filterText`.
adjust_start_col() is explained here:
0ea8dfeb3d/runtime/lua/vim/lsp.lua (L2334-L2351)
The `filterText` field is used in the following situations rather than as
a condition for obtaining column values:
1. Real-time filtering: When the user types characters in the editor, the
language server can use the filterText field to filter the list of
suggestions and only return suggestions that match the typed characters. This
helps to provide more precise recommendations.
2. Fuzzy matching: The filterText field can be used to perform fuzzy matching,
allowing matching in the middle or beginning of input characters, not limited
to prefix matching. This can provide a more flexible code completion
experience.
Inspecting usage of `filtertext` in vim-lsp and coc and lsp-mode:
- vim-lsp uses a `refresh_pattern` to judge filterText as completionitem word
(although I think this is not the correct usage).
- coc uses it for filtering.
Fix#22803
Problem: luals returns stricter diagnostics with bundled luarc.json
Solution: Improve some function and type annotations:
* use recognized uv.* types
* disable diagnostic for global `vim` in shared.lua
* docs: don't start comment lines with taglink (otherwise LuaLS will interpret it as a type)
* add type alias for lpeg pattern
* fix return annotation for `vim.secure.trust`
* rename local Range object in vim.version (shadows `Range` in vim.treesitter)
* fix some "missing fields" warnings
* add missing required fields for test functions in eval.lua
* rename lsp meta files for consistency
PR #23689 assumes `client.config.capabilities.workspace.didChangeWatchedFiles`
exists when checking `dynamicRegistration`, but thats's true only if it was
passed to `vim.lsp.start{_client}`.
This caused #23806 (still an issue in v0.9.1; needs manual backport), but #23681
fixed it by defaulting `config.capabilities` to `make_client_capabilities` if
not passed to `vim.lsp.start{_client}`.
However, the bug resurfaces on HEAD if you provide a non-nil `capabilities` to
`vim.lsp.start{_client}` with missing fields (e.g: not made via
`make_client_capabilities`).
From what I see, the spec says such missing fields should be interpreted as an
absence of the capability (including those indicated by missing sub-fields):
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#clientCapabilities
Also, suggest `vim.empty_dict()` for an empty dict in
`:h vim.lsp.start_client()` (`{[vim.type_idx]=vim.types.dictionary}`
no longer works anyway, probably since the cjson switch).
* fix(lsp): replace @private with @nodoc for public client functions
To prevent lua-ls warnings in plugins which use the functions.
* fix(lsp): remove duplicate type annotations/class definitions
These annotations became duplicate with https://github.com/neovim/neovim/pull/23750
* docs(lua): teach lua2dox how to table
* docs(lua): teach gen_vimdoc.py about local functions
No more need to mark local functions with @private
* docs(lua): mention @nodoc and @meta in dev-lua-doc
* fixup!
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
There is no need for two ways to access all clients of a buffer.
This doesn't add a `vim.deprecate` call yet, as the function is probably
used a lot, but removes it from the documentation and annotates it with
`@deprecated`
Enforce consistent terminology (defined in
`gen_help_html.lua:spell_dict`) for common misspellings.
This does not spellcheck English in general (perhaps a future TODO,
though it may be noisy).
Add automatic refresh and a public interface on top of #23736
* add on_reload, on_detach handlers in `enable()` buf_attach, and
LspDetach autocommand in case of manual detach
* unify `__buffers` and `hint_cache_by_buf`
* use callback bufnr in `on_lines` callback, bufstate: remove __index override
* move user-facing functions into vim.lsp.buf, unify enable/disable/toggle
Closes#18086
`client.messages` could grow unbounded because the default handler only
added new messages, never removing them.
A user either had to consume the messages by calling
`vim.lsp.util.get_progress_messages` or by manually removing them from
`client.messages.progress`. If they didn't do that, using LSP
effectively leaked memory.
To fix this, this deprecates the `messages` property and instead adds a
`progress` ring buffer that only keeps at most 50 messages. In addition
it deprecates `vim.lsp.util.get_progress_messages` in favour of a new
`vim.lsp.status()` and also promotes the `LspProgressUpdate` user
autocmd to a regular autocmd to allow users to pattern match on the
progress kind.
Also closes https://github.com/neovim/neovim/pull/20327
If the server sends the positionEncoding capability in its
initialization response, automatically set the client's offset_encoding
to use the value provided.
BREAKING CHANGE: LspRequest is no longer a User autocmd but is now a
first class citizen.
LspRequest as a User autocmd had limited functionality. Namely, the only
thing you could do was use the notification to do a lookup on all the
clients' requests tables to figure out what changed.
Promoting the autocmd to a full autocmd lets us set the buffer the
request was initiated on (so people can set buffer-local autocmds for
listening to these events).
Additionally, when used from Lua, we can pass additional metadata about
the request along with the notification, including the client ID, the
request ID, and the actual request object stored on the client's
requests table. Users can now listen for these events and act on them
proactively instead of polling all of the requests tables and looking
for changes.
- `client.dynamic_capabilities` is an object that tracks client register/unregister
- `client.supports_method` will additionally check if a dynamic capability supports the method, taking document filters into account. But only if the client enabled `dynamicRegistration` for the capability
- updated the default client capabilities to include dynamicRegistration for:
- formatting
- rangeFormatting
- hover
- codeAction
- hover
- rename
* feat(lua): vim.tbl_contains supports general tables and predicates
Problem: `vim.tbl_contains` only works for list-like tables (integer
keys without gaps) and primitive values (in particular, not for nested
tables).
Solution: Rename `vim.tbl_contains` to `vim.list_contains` and add new
`vim.tbl_contains` that works for general tables and optionally allows
`value` to be a predicate function that is checked for every key.