summaryrefslogtreecommitdiffstatshomepage
path: root/test/functional/plugin/lsp/folding_range_spec.lua
AgeCommit message (Collapse)AuthorFiles
2026-04-15feat(lsp): highlight foldtext via treesitter #38789Yi Ming1
Problem: To support `collapsedText`, which allows the LSP server to determine the content of the foldtext, we provided `vim.lsp.foldtext()`. However, such content does not have highlighting. Solution Treat the filetype of `collapsedText` as the filetype of the corresponding buffer and use tree-sitter to highlight it.
2025-08-18refactor(lsp): use `vim.lsp._capability.enable` internallyYi Ming1
2025-08-18refactor(lsp): correct enable marker nameYi Ming1
2025-07-13refactor(lsp): utility functions for `enable()/is_enabled()`Yi Ming1
2025-07-07refactor(lsp): stateful data abstraction, vim.lsp.Capability #34639Yi Ming1
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: https://github.com/neovim/neovim/blob/fb8dba413f2bcaa61c15d1854b28112e3e91a035/runtime/lua/vim/lsp/semantic_tokens.lua#L192-L198 - inlay hints, folding ranges, document color https://github.com/neovim/neovim/blob/fb8dba413f2bcaa61c15d1854b28112e3e91a035/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-03-15docs: miscdundargoc1
Co-authored-by: Au. <acehinnnqru@gmail.com> Co-authored-by: Daniel Rainer <daniel.rainer@localhost> Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Lewis Russell <lewis6991@gmail.com> Co-authored-by: Luuk van Baal <luukvbaal@gmail.com> Co-authored-by: Pierre Barbin <pierre@heitzsystem.com> Co-authored-by: Riley Bruins <ribru17@hotmail.com> Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com> Co-authored-by: phanium <91544758+phanen@users.noreply.github.com> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2024-11-29feat(lsp): support `textDocument/foldingRange` (#31311)Yi Ming1
* 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