Commit Graph

10 Commits

Author SHA1 Message Date
7ac4cbcd2e refactor(lsp): utility functions for enable()/is_enabled() 2025-07-13 11:03:22 +08:00
8d5452c46d refactor(lsp): stateful data abstraction, vim.lsp.Capability #34639
Problem:
Closes #31453

Solution:
Introduce `vim.lsp.Capability`, which may serve as the base class for
all LSP features that require caching data. it
- was created if there is at least one client that supports the specific method;
- was destroyed if all clients that support the method were detached.

- Apply the refactor for `folding_range.lua` and `semantic_tokens.lua`.
- Show active features in :checkhealth.

Future:
I found that these features that are expected to be refactored by
`vim.lsp.Capability` have one characteristic in common: they all send
LSP requests once the document is modified. The following code is
different, but they are all for this purpose.

- semantic tokens:
fb8dba413f/runtime/lua/vim/lsp/semantic_tokens.lua (L192-L198)
- inlay hints, folding ranges, document color
fb8dba413f/runtime/lua/vim/lsp/inlay_hint.lua (L250-L266)

I think I can sum up this characteristic as the need to keep certain
data synchronized with the latest version computed by the server.
I believe we can handle this at the `vim.lsp.Capability` level, and
I think it will be very useful.

Therefore, my next step is to implement LSP request sending and data
synchronization on `vim.lsp.Capability`, rather than limiting it to the
current create/destroy data approach.
2025-07-07 03:51:30 +00:00
528381587b refactor(lsp): redesign LSP folding state #34469 2025-06-19 06:23:40 -07:00
cd06e0c9d6 fix(lsp): include client ID when receiving unknown fold kind (#34535) 2025-06-16 19:36:06 -07:00
35756022cb fix(lsp): advertise supported fold kinds (#34461)
This commit also makes it so that folds which have an unsupported fold
kind have their `kind` ignored.
2025-06-16 16:05:00 -04:00
fed9069b8d fix(lsp): avoid foldclose() after current window-buffer changed #33901
Problem:
Because the buffer in the window may change before the request is completed, foldclose() might be executed on the wrong buffer.

Solution:
Avoid that.
2025-05-22 03:16:28 -07:00
be8d87014c fix(lsp): on detach, cancel pending foldingRange requests #31509
Problem:
1. Open a relatively large file (so the server needs some time to
   process the request).
2. Then immediately execute `:bdelete`.
3. Once the request is completed, the handler will obtain the bufstate
   of a buffer already unloaded.

    Error executing vim.schedule lua callback: ...7841_1/share/nvim/runtime/lua/vim/lsp/_folding_range.lua:119: assertion failed!
    stack traceback:
            [C]: in function 'assert'
            ...7841_1/share/nvim/runtime/lua/vim/lsp/_folding_range.lua:119: in function 'multi_handler'
            ...7841_1/share/nvim/runtime/lua/vim/lsp/_folding_range.lua:140: in function 'handler'
            ...HEAD-c137841_1/share/nvim/runtime/lua/vim/lsp/client.lua:669: in function ''
            vim/_editor.lua: in function <vim/_editor.lua:0>

Solution:
On detach, cancel all pending textDocument_foldingRange requests.
2025-02-12 06:22:59 -08:00
09e01437c9 refactor: use nvim.foo.bar format for autocommand groups 2025-01-14 21:25:25 -08:00
fac96b72a5 fix(lsp): add foldingrange method support check #31463
Problem: The folding_range request method assumes that the client
supports the method

Solution: Add a capability guard to the call
2024-12-06 10:09:07 -08:00
a1e313ded6 feat(lsp): support textDocument/foldingRange (#31311)
* 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
2024-11-29 12:40:32 +00:00