neovim - Vim-fork focused on extensibility and usability

Age	Commit message (Collapse)	Author	Files
2026-03-18	feat(lsp): migrate `document_color` to capability framework (#38344)	Maria Solano	1
	* feat(lsp): migrate `document_color` to capability framework * feat(lsp): use `vim.Range` in `document_color` module
2026-02-03	feat(lsp)!: reimplement `textDocument/codeLens` as decoration provider	Yi Ming	1

2025-12-06	refactor(lsp): unify capability checks and registration #36781	Tristan Knight	1
	Problem: Our LSP type system didnt have a concept of RegistrationMethods, this is where the method to dynamically register for a capability is sent to a different method endpoint then is used to call it. Eg `textDocument/semanticTokens` rather than the specific full/range/delta methods Solution: Extended generator to create `vim.lsp.protocol.Methods.Registration` with these registration methods. Also extend `_request_name_to_client_capability` to cover these methods. Adjust typing to suit
2025-11-10	fix(lsp): deprecate `vim.lsp.get_buffers_by_client_id` (#36449)	Maria Solano	1

2025-08-25	feat(lsp): support `textDocument/inlineCompletion`	Yi Ming	1

2025-08-18	refactor(lsp): use `vim.lsp._capability.enable` internally	Yi Ming	1

2025-08-18	refactor(lsp): no longer rely on `LspDetach` for detaching capabilities	Yi Ming	1

2025-08-18	refactor(lsp): move `util.enable` to `capability.enable`	Yi Ming	1

2025-08-17	refactor(lsp): change capability name to snake case	Yi Ming	1

2025-08-17	refactor(lsp): register all derived `Capability` prototypes	Yi Ming	1

2025-08-17	refactor(lsp): define `Capability.on_attach`	Yi Ming	1

2025-07-07	refactor(lsp): stateful data abstraction, vim.lsp.Capability #34639	Yi Ming	1
	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.