neovim language server client

rumpelsepp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

andersondanilo commented 3 years ago

I am using this project and it's very good

bluz71 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

@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.

dense-analysis / ale

neovim language server client #3528