Ale: Clarification about ALE and autozimu/LanguageClient-neovim

Created on 13 May 2018  路  11Comments  路  Source: dense-analysis/ale

This is perhaps something fitting the FAQ.

It's my understanding that ALE implements LSP's protocol as a client and supports some servers.

The questions are:

  1. Does ALE start and talk to LSP compatible servers by itself or does it use other vim libraries as intermediaries?
  2. LanguageClient-neovim is strictly a LSP client.
    2.1. What is the feature overlap between ALE and LanguageClient-neovim?
    2.2. Does ALE aim to implement everything LanguageClient-neovim currently implements?
    2.3. Should the user be advised to pick one or the other? (e.g. some linters/LSP servers can be quite memory hungry with large projects, running multiple can have a performance impact on the system)

Most helpful comment

I'll write up basically a dump of my thoughts on LSP stuff so far here, as I get a few questions about it.

I've heard the "not a good idea" argument a few times, but that argument is subjective. What isn't a good idea to you, might seem like a great idea to someone else. What you are _really_ saying when you say that is, "I don't want this." The way to address "I don't want this" for users is to use a combination of not enabling certain features by default, and letting you disable the things you don't want that are on by default. You shouldn't pay for what you don't use. ALE is pretty good about that.

I personally want to add more and more LSP support to ALE as time goes on, as I think it's going to matter more and more. There has to be some integration with LSP clients and ALE to make diagnostics work properly in combination with other tools. I wouldn't consider integrating with LanguageClient-neovim, as I have a strict requirement for 100% VimL plugins, and I would only consider relaxing that to _maybe_ including Python. (See: deoplete) The plugins also have to support Vim 8 and many versions of NeoVim well, for me to consider integrating with them. LSP plugins which are written in VimL, I would consider integrating with. Thus far, I think ALE's LSP client implementation in VimL is probably the most mature that I've seen, so far.

Let me know what I could add to the documentation to make things clearer. I am typically against adding comparisons between ALE and other plugins to the ALE documentation. I believe that's something that belongs in an external wiki, or a series of articles. See this Slant page for an example comparison of linter plugins: https://www.slant.co/topics/4017/versus/~ale_vs_syntastic_vs_neomake The wiki I recommend editing is the Vim Wikia site. http://vim.wikia.com/wiki/Vim_Tips_Wiki Putting those kinds of details in an external Wiki means that I don't have to merge commits for that kind of information, so it's easier to keep up to date.

All 11 comments

I don't think make a linter do things that beyond lint files is a good idea.
But I do think there should be a replacement of LanguageClient-neovim for LSP stuff, LanguageClient-neovim have so many problems.

I don't think make a linter do things that beyond lint files is a good idea.

This is arguable and unrelated to what I'm asking here. According to the docs ALE already supports some parts of LSP.

But I do think there should be a replacement of LanguageClient-neovim for LSP stuff, LanguageClient-neovim have so many problems.

I'm also explicitly not saying ALE or LanguageClient-neovim is better or worse.

What I'm after is detailed information to help potential users (myself included) to decide if they want ALE, LanguageClient-neovim or both (if both is an option).

I'll write up basically a dump of my thoughts on LSP stuff so far here, as I get a few questions about it.

I've heard the "not a good idea" argument a few times, but that argument is subjective. What isn't a good idea to you, might seem like a great idea to someone else. What you are _really_ saying when you say that is, "I don't want this." The way to address "I don't want this" for users is to use a combination of not enabling certain features by default, and letting you disable the things you don't want that are on by default. You shouldn't pay for what you don't use. ALE is pretty good about that.

I personally want to add more and more LSP support to ALE as time goes on, as I think it's going to matter more and more. There has to be some integration with LSP clients and ALE to make diagnostics work properly in combination with other tools. I wouldn't consider integrating with LanguageClient-neovim, as I have a strict requirement for 100% VimL plugins, and I would only consider relaxing that to _maybe_ including Python. (See: deoplete) The plugins also have to support Vim 8 and many versions of NeoVim well, for me to consider integrating with them. LSP plugins which are written in VimL, I would consider integrating with. Thus far, I think ALE's LSP client implementation in VimL is probably the most mature that I've seen, so far.

Let me know what I could add to the documentation to make things clearer. I am typically against adding comparisons between ALE and other plugins to the ALE documentation. I believe that's something that belongs in an external wiki, or a series of articles. See this Slant page for an example comparison of linter plugins: https://www.slant.co/topics/4017/versus/~ale_vs_syntastic_vs_neomake The wiki I recommend editing is the Vim Wikia site. http://vim.wikia.com/wiki/Vim_Tips_Wiki Putting those kinds of details in an external Wiki means that I don't have to merge commits for that kind of information, so it's easier to keep up to date.

Now, for your actual questions above...

Does ALE start and talk to LSP compatible servers by itself or does it use other vim libraries as intermediaries?

ALE connects directly to LSP servers with code written entirely in VimL, with no need for anything other than what comes with Vim 8 or NeoVim. Currently ALE doesn't connect via TCP sockets, but adding support for that in Vim 8 wouldn't take very long at all, I just haven't had a couple of days in which to do the work for it. Implementing TCP connections for NeoVim is significantly harder, but might not matter as soon as native support for LSP connections lands in NeoVim anyway.

What is the feature overlap between ALE and LanguageClient-neovim?

Both implement parts of what a language client ought to support, such as diagnostics, completion, "go to definition," etc. ALE implements a Hell of a lot more functionality for diagnostics, as linting is ALE's primary goal, and lets you combine LSP diagnostics with external tools. ALE also implements tsserver support, as the protocol is just similar enough to LSP. For example, you can combine results for tsserver with eslint from the CLI, etc.

Does ALE aim to implement everything LanguageClient-neovim currently implements?

If I have to say "yes" or "no," I'd lean towards "no," but ALE might end up implementing basically everything anyway. It all depends on making it so you don't pay for what you don't use. The code for "go to definition" doesn't need to ever be loaded if you don't use the command.

Should the user be advised to pick one or the other? (e.g. some linters/LSP servers can be quite memory hungry with large projects, running multiple can have a performance impact on the system)

I'm not sure. Pick whatever works best for you. Maybe use both if you want to, accepting some need to configure things heavily and some extra resource overhead. It's still probably going to be lighter on your system than running Eclipse. I want to implement just enough of the LSP features most people want, so they don't need to run something else, just for a couple of extra useful things.

@w0rp Thanks, for the detailed feedback. This covers what I wanted to know and then some.

Not sure what's the policy on documentation questions so feel free to close if that's the right action to follow.

I like to keep documentation issues open until I feel like the person who was confused is satisfied that things are more intuitive.

LanguageClient-neovim have so many problems

@chemzqm Like what, for example? I'm just starting to use language servers in neovim, so I'd like to know more and perhaps possible alternatives.

@chemzqm Thanks! I'm using ncm2, and while it supports integration with LanguageClient-neovim, it looks like coc.nvim is not yet supported, unfortunately.

@balta2ar coc.nvim has it's own languageclient implementation, it's not designed to work with other languageclient plugin.

This has gone off topic, so I'm locking this now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

glepnir picture glepnir  路  3Comments

trevordmiller picture trevordmiller  路  4Comments

aressler38 picture aressler38  路  3Comments

sublee picture sublee  路  3Comments

trevordmiller picture trevordmiller  路  3Comments