How to run LSP actions (formatting, linting, etc.) with *specific* null-ls source only?

[wookayin]

The use case I want is to run some LSP actions (vim.lsp.buf.{format,code_action,hover,etc.}) with specific null-ls sources. For example, if you have multiple formatter available for python, say black, yapf, and isort, then you may want to run isort only -- not touching anything with black or yapf.

vim.lsp.buf.format({ filter = ... }) allows which LSP client to use only for this one-shot formatting, but in our case all three formatters have a facade LSP client, null-ls.

One possible way might be to: temporarily disable all other sources, null_ls.sources.disable(query) then format then null_ls.source.enable(query) (recover the previous state). But this seems quite complicated and verbose.

Is there any better way to try applying one specific null-ls sources when doing LSP actions, say as some additional context argument to vim.lsp.buf.XXX or custom APIs that can make LSP requests?

[jose-elias-alvarez]

We've had similar requests in the past, but I think there's a sort of impedance mismatch here. null-ls is meant to mimic how LSP servers behave, and LSP servers generally don't provide this level of granularity - for example, if you send a formatting request, the server will respond with a list of changes based on how the server was configured in the first place, so that's what we do too.

I'm open to solutions here, but given the mismatch between our architecture and this sort of functionality, I'm not sure it'd be worth it, especially given the existence of other projects better suited to this sort of workflow like Neoformat and nvim-lint (as well as simpler one-off solutions like :!isort %).

[wookayin]

Thank you. So it seems we don't have a solution to this yet, leaving as a feature request.

Using Neoformat, nvim-lint, etc. or other plugins (e.g., I used isort.nvim before) but I would want to avoid having two plugins for the same job/purpose (and null-ls and other formatters may actually behave slightly differently). Having a consistent configuration and executables for Neoformat and null-ls would be non-trivial. So I would say there is some benefit.

For diagnostics, it would be tricky to running only one sources because we may need to cache other sources' result if we do not temporarily run other sources but still want to retain their diagnostics results. It will be better to simply disable one source on demand using the disable/enable API.

However, when it comes to formatting or some one-time actions, textDocument/formatting may have some runtime options as per FormattingOptions (e.g., tabSize, etc.). So we might want to make use of the lsp request params either as part of LSP specification or null-ls-specific protocol (e.g., DocumentFormattingParams to specify a filter for which null-ls sources to run. Let me work on that idea in a near future if that sound good to you.

LSP servers behave, and LSP servers generally don't provide this level of granularity

So I believe we can have some runtime params for LSP requests, either LSP standard specs and non-standard (an extension specific to particular LSP implementations) ones.

[jose-elias-alvarez]

You're right, doing it via params would be the most LSP-like solution. Since the specification allows for "further properties" I think that would be the place to do it, but since we'd be limited to sending JSON in the request, we also wouldn't be able to provide a ton of granularity. Sounds like it might be worth pursuing, though.