Justin M. Keyes

> Could we move this to the `get_doc` function where we already encapsulate the logic around an item’s documentation? @MariaSolOs does the latest PR look like what you are expecting?

what version of vscode is used by your Cursor?

waiting on the requested changes, else this is wontfix

To avoid making `vim.lsp.config` a special-case "inner platform", [extending `vim.tbl_deep_extend()`](https://github.com/neovim/neovim/pull/33579#issuecomment-2827481259) seems like a good option. Its `behavior` arg could take a function: ```lua vim.tbl_deep_extend(function(key, val) ... end, ...) ``` Then...

> overcomplicate things for almost no benefit. ~~Adding a [`merge` item](https://github.com/neovim/neovim/issues/33577#issuecomment-2832866835) to vim.lsp.config, which is passed along to `tbl_deep_extend(behavior: string|fun(key,val))`, is a complete solution, that also allows us to keep...

> having `LspInit`, `LspBeforeInit`, etc. events would be quite useful regardless all of the surface area we add, is a new place that needs to be debugged when things go...

@titaniumtraveler isn't that the same as https://github.com/neovim/neovim/issues/32287#issuecomment-2835155023 ? We seem to be aligned on that. Though https://github.com/neovim/neovim/pull/33833#issuecomment-2898785995 raises an interesting alternative(?): > We probably also need to reconsider the caching...

> I mean I wouldn't _really_ expect users to constantly restart their LSP-Servers, so I'm not _quite_ sure caching is actually useful? Without caching, wouldn't the lsp configs need to...

[This](https://github.com/neovim/nvim-lspconfig/issues/3850#issuecomment-2901164705) reminds me that users have the option of defining `reuse_client` to set arbitrary config fields dynamically. So I wonder how big the problem actually is here.

I don't get why this requires so much new code. Why does mapping information to extmarks require 100s of lines of code for every random module that needs it? And...