summaryrefslogtreecommitdiffstatshomepage
path: root/runtime/lua/vim/lsp/_folding_range.lua
AgeCommit message (Collapse)AuthorFiles
2026-04-22perf(lsp): clear table by table.clear() #39222Yi Ming1
benchmark: https://gist.github.com/ofseed/6224529d77c016c36f7ab2f977059848 local rounds = tonumber(arg[1]) or 1000 local count = tonumber(arg[2]) or 1000 -- Load the table.clear function. local clear = require("table.clear") local function fill(t, n) for i = 1, n do t[i] = i end end local function bench_reassign(n_rounds, n_items) local t = {} local start = os.clock() for _ = 1, n_rounds do t = {} collectgarbage("collect") fill(t, n_items) end return os.clock() - start end local function bench_reassign_no_gc(n_rounds, n_items) local t = {} local start = os.clock() for _ = 1, n_rounds do t = {} fill(t, n_items) end return os.clock() - start end local function bench_clear(n_rounds, n_items) local t = {} local start = os.clock() for _ = 1, n_rounds do clear(t) fill(t, n_items) end return os.clock() - start end -- Warm up LuaJIT before the real benchmark. do local t = {} for _ = 1, 2000 do clear(t) fill(t, count) end end collectgarbage("collect") local reassign_time = bench_reassign(rounds, count) collectgarbage("collect") local reassign_no_gc_time = bench_reassign_no_gc(rounds, count) collectgarbage("collect") local clear_time = bench_clear(rounds, count) print(string.format("rounds=%d count=%d", rounds, count)) print(string.format("t = {} + GC : %.6f s", reassign_time)) print(string.format("t = {} : %.6f s", reassign_no_gc_time)) print(string.format("table.clear : %.6f s", clear_time)) print(string.format("vs + GC : %.2fx", reassign_time / clear_time)) print(string.format("vs no GC : %.2fx", reassign_no_gc_time / clear_time)) benchmark result: rounds=1000 count=1000 t = {} + GC : 0.022469 s t = {} : 0.002570 s table.clear : 0.000387 s vs + GC : 58.06x vs no GC : 6.64x `count` is how many items the table has, and `round` is how many rounds we fill the table, clear, and then refill it. `table = {}` is clear the table by resigning a new empty one, because this script does not run persistently like nvim so GC is not triggered, so I added another extreme control group that manually triggers GC.
2026-04-15refactor: update usages of deprecated "buffer" param #39089Justin M. Keyes1
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.
2026-04-08feat(api): rename buffer to buf #35330Jordan1
Problem: `:help dev-name-common` states that "buf" should be used instead of "buffer" but there are cases where buffer is mentioned in the lua API. Solution: - Rename occurrences of "buffer" to "buf" for consistency with the documentation. - Support (but deprecate) "buffer" for backwards compatibility. Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
2026-03-20fix(lsp): unify LSP error logging prefixes #38354Yi Ming1
Problem The format of LSP log messages is inconsistent; some include underscores, while others are not logged at all. Solution Standardize log recording and unify the log message prefixes with the module names.
2026-03-12docs: use "ev" convention in event-handlersJustin M. Keyes1
Problem: In autocmd examples, using "args" as the event-object name is vague and may be confused with a user-command. Solution: Use "ev" as the conventional event-object name.
2025-11-26fix(lsp): ignore invalid fold ranges (#36708)Miika Tuominen1
2025-10-04fix(lsp): deprecate `vim.lsp.protocol.Methods` (#35998)Maria Solano1
2025-08-28refactor(lua): consistent use of local aliasesChristian Clason1
2025-08-24fix(lsp): check whether buffer is valid when scheduled #35461Yi Ming1
2025-08-18refactor(lsp): use `vim.lsp._capability.enable` internallyYi Ming1
2025-08-18refactor(lsp): correct enable marker nameYi Ming1
2025-08-17refactor(lsp): change capability name to snake caseYi Ming1
2025-08-17refactor(lsp): register all derived `Capability` prototypesYi Ming1
2025-08-17refactor(lsp): define `Capability.on_attach`Yi 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-06-19refactor(lsp): redesign LSP folding state #34469Yi Ming1
2025-06-16fix(lsp): include client ID when receiving unknown fold kind (#34535)Maria José Solano1
2025-06-16fix(lsp): advertise supported fold kinds (#34461)Riley Bruins1
This commit also makes it so that folds which have an unsupported fold kind have their `kind` ignored.
2025-05-22fix(lsp): avoid `foldclose()` after current window-buffer changed #33901Yi Ming1
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-02-12fix(lsp): on detach, cancel pending foldingRange requests #31509Yi Ming1
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-01-14refactor: use nvim.foo.bar format for autocommand groupsMaria José Solano1
2024-12-06fix(lsp): add foldingrange method support check #31463Tristan Knight1
Problem: The folding_range request method assumes that the client supports the method Solution: Add a capability guard to the call
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