Should we replace our monkeypatching of vim.lsp.Client.supports_method with neovim/LSP's support for dynamic capabilities?

[jfly]

See

none-ls.nvim/lua/null-ls/client.lua

Lines 78 to 84 in caf8556

	if vim.fn.has("nvim-0.11") == 1 then
	new_client.supports_method = function(_, method)
	return supports_method(method)
	end
	else
	new_client.supports_method = supports_method
	end

IIUC, we're monkeypatching supports_method so we can dynamically respond to capabilities (as documented here). This works, but feels brittle to me (we recently had to change this to a class method).

It seems to me that we could we rid of this monkeypatching if we instead leveraged LSP's support for dynamic capabilities. See:

• feat(lsp): initial support for dynamic capabilities neovim/neovim#23681
• https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#client_registerCapability

Perhaps we aren't doing that just because none-ls predates this functionality? Is there some other reason not to use this?

[jfly]

See #230 for a more extreme idea inspired by this question.

[barrettruth]

This seems like a good idea. Took me a good 30 minutes to wrap my head around dynamic registration. Just so we're on the same page, can you give me an example of a use case for this? Further, what parts of the none-ls codebase would have to change? I'm guessing we have some real-world servers we could parrot the dynamic code from?

[jfly]

Caveat: I'm not entirely sure I have my head wrapped around what none-ls is doing, but I believe the idea is for it to only advertise itself as capable of certain things (formatting, for example), if there's a none-ls builtin enabled that knows how to format the given file.

[barrettruth]

I think you mean only register certain capabilities to the neovim client if it is capable of performing certain things (right? for both of our understanding).

TBH, I'm not sure this make a sense as a function of registered sources? For example, are you saying if I open filetype a, I dynamically register some capability, then if I open filetype b that's unsupported, I'd unregister it?

I guess what I'm saying is this sounds like a per-LSP feature. And null-ls is a wrapper, so it's like providing that per-LSP feature, for potentially many LSPs at the same time, but all exposed through one interface. Not sure if that makes sense (both my explanation and the idea itself lol)...

[jfly]

I guess I don't really know how supports_method is used in practice.

For example, are you saying if I open filetype a, I dynamically register some capability, then if I open filetype b that's unsupported, I'd unregister it?

Good question. Our implementation looks at a global variable (vim.bo.filetype), so it assuming supports_method is always called (and not cached somewhere), it seems like it would handle the filetype a and filetype b scenario you describe.

I now sort of doubt that that's achievable with LSP's dynamic capabilities, so I think the answer to my original question is "no, it's not possible".

Now I'm wondering if there's an alternative way to build none-ls that actually registers itself as a different LSP per builtin. That seems like it would avoid the need for monkeypatching supports_method.