neovim language server client

[rumpelsepp]

Just want to drop this information and a question. neovim's next version will provide a builtin language server client. Will ale be able to somehow use this client? Are there any plans?

[w0rp]

I'll leave this issue open. We will probably use some part of it, if it makes sense. The most sensible thing to do would be to make it easy to treat it as another source of diagnostics. See :help ale-lint-other-sources.

[weeman1337]

I found this project: https://github.com/nathunsmitty/nvim-ale-diagnostic

[andersondanilo]

I am using this project and it's very good

[bluz71]

I'll leave this issue open. We will probably use some part of it, if it makes sense. The most sensible thing to do would be to make it easy to treat it as another source of diagnostics. See :help ale-lint-other-sources.

Going the other way is also highly desirable (at least for me), that being for ALE to be a source for Neovim's 0.6 diagnostic subsystem.

Use case:

• User such as myself is already Neovim's LSP client for all manner of LSP things

• Augment with non-LSP linters: standard (JS), standardrb & mdl (for example)

• Accumulate all errors and warnings into a single diagnostics source (in this Neovim's Diagnostic subsystem). Yes, I know there is a bridge (noted above) to feed Neovim LSP diagnostics to ALE; however I prefer Neovim's diagnostic display.

Noting that upcoming Neovim 0.6 has split Diagnostics out of LSP into it's own top-level module.

Hopefully, if possible, ALE could be directed to feed errors and warnings into Neovim's diagnostic module.

Yes, I am aware that null-ls exists, but ALE's setup is so much simpler and easier. That's the great thing about ALE, it already has most stuffed baked in.

My 2cents.

[bb010g]

I would love this. I want to use Neovim's standard functionality, but also love how much ALE just works for any repository I walk into. ALE's auto-detection is especially useful when most of your tools are project-local; whatever's set up in the project environment will load in and it's easy to see what might need to be added via :ALEInfo.

[w0rp]

I'm adding this to the milestone to think about it again, but I might not do it. Just because I/we wrote a working LSP implementation that works basically the same in Vim 8.0 before Neovim's LSP client was written, and using that as the base for everything makes it easier to maintain ALE. Splitting the implementation might make ALE better in Neovim at the expense of making Vim worse, and that's a non-starter for me. I will never make the Vim experience worse to favour Neovim.

[w0rp]

We support displaying via Neovim diagnostics now, and it will be the default by ALE 4.0.0 in new enough versions of ALE: https://github.com/dense-analysis/ale/issues/4005

I'm going to support all/most of the existing options people already use for configuring how diagnostics are sent to Neovim.

[w0rp]

@Angelchev has experienced significant performance issues when running Pyright via Neovim's native language server client code instead of ALE's in Neovide. The ALE Vimscript actually performs better, which surprises me, and I can clearly see the difference in his editor. If we ever use the Neovim native client, we'll need to make sure it doesn't actually deliver worse performance in some cases.

ALE will now by default display problems using Neovim's diagnostic API, and automatically disable linters when nvim-lspconfig configurations are detected that match them. That should prevent conflicts between the two.