Why is none-ls a Neovim lua plugin rather than a full fledged language server?

[jfly]

Could none-ls instead be implemented as proper language server that under the hood execs various shell commands?

I recently learned about our monkeypatching of vim.lsp.Client.supports_method, which isn't an option for a true language server. Are there other things like this lurking in our codebase?

The benefit of making this a proper language server is that other editors besides Neovim (such as Helix) could benefit from the work we're doing here.

[barrett-ruth]

Not really sure about this either, don't have enough experience in none-ls. Some thoughts:

• there is a lot of duplication (like LSP methods), which would be nice to remove
• How would you expose a uniform LSP client interface for null-ls? How would this work with, you know, null-ls offering a bunch of sources?
• I'm not sure how strong the support is for this project, and the maintenance burden would definitely, like, permanently increase (LSP compatibiliy + source-specific things)

[jfly]

How would you expose a uniform LSP client interface for null-ls? How would this work with, you know, null-ls offering a bunch of sources?

I think this would "just" be a config file that lives somewhere that enables whatever sources you want.

the maintenance burden would definitely, like, permanently increase (LSP compatibiliy + source-specific things)

I don't think I agree with this. The LSP spec is slow moving and preserves backwards compatibility, whereas we are currently coding against a more ambiguous Lua abstraction (which has been a recent source of pain: 94d024e, 3c4ca98, #229.

For the record, I don't actually think this is a direction none-ls should go. The installation + configuration churn alone would alienate our users. I'm asking about this more as a "is this a good idea for a new project inspired by none-ls, or is there something I'm not seeing here?" question.

[barrett-ruth]

ic. makes sense