aboutsummaryrefslogtreecommitdiff
path: root/test/functional/plugin/lsp/folding_range_spec.lua
Commit message (Collapse)AuthorAge
* fix(lsp): silently ignore unknown folding range kinds (#41964)Maria Solano2026-09-18
|
* feat(lsp): support `workspace/foldingRange/refresh` #41780Volodymyr Chernetskyi2026-09-09
| | | | | | | | | | | Problem: Servers cannot request refreshing stale LSP folding ranges after a project-wide change. Solution: Advertise `workspace.foldingRange.refreshSupport` and re-request folding ranges for active buffers when handling `workspace/foldingRange/refresh`. AI-assisted
* fix(lsp): separate adjacent nested folding ranges #41428wrvsrx2026-08-31
| | | | | | | | | Problem: Folding range markers are overwritten while ranges are evaluated. A range ending on a row can hide another range starting there, and multiple nested ranges ending together emit only the innermost ending level. Solution: Track starts and the number of ends per row before emitting markers. Prefer starts on shared boundary rows and use the outermost level when nested ranges end together. AI-assisted
* test(harness): migrate away from magic globalsJustin M. Keyes2026-07-21
| | | | | | | | | | | | | | | | | | | | | Problem: The magic globals `it`, `describe`, etc., are more trouble than they are worth. - Hooking into `after_each` requires `getfenv()` hacks. - They confuse luals/emmylua, because the top-level `.luarc.json` isn't merged with `test/.luarc.json` (apparently a luals limitation?) - They totally defeat discoverability because the user just has to "know" about the various magic symbols. So they harm DX, which means they serve no purpose at all. Solution: - Expose the test API from `testutil`, so tests can call `t.it()`, `t.describe()`, etc., in the conventional way. - Drop `getfenv()` hacks. - Drop the `setfenv()` injection in `load_chunk`. - Drop `test/_meta.lua`.
* fix(tests): use builtin default attributes in more placesbfredl2026-06-19
|
* feat(lsp): highlight foldtext via treesitter #38789Yi Ming2026-04-15
| | | | | | | | | | 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.
* refactor(lsp): use `vim.lsp._capability.enable` internallyYi Ming2025-08-18
|
* refactor(lsp): correct enable marker nameYi Ming2025-08-18
|
* refactor(lsp): utility functions for `enable()/is_enabled()`Yi Ming2025-07-13
|
* refactor(lsp): stateful data abstraction, vim.lsp.Capability #34639Yi Ming2025-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* docs: miscdundargoc2025-03-15
| | | | | | | | | | | | | 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>
* feat(lsp): support `textDocument/foldingRange` (#31311)Yi Ming2024-11-29
* 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