Add support for Microsoft's python-language-server

[w0rp]

Name: Microsoft's python-language-server
URL: https://blogs.msdn.microsoft.com/pythonengineering/2018/07/18/introducing-the-python-language-server/

Microsoft have created a new language server for Python which will be used in VSCode. Once the stand alone component is released, it should be superior to the existing language server tool for Python.

[meunierd]

It looks like this has been released: https://github.com/Microsoft/python-language-server

[petr-k]

This would be a wonderful addition. Is it a big undertaking to add a new linter?

[w0rp]

It should be easy to do.

[alexcardell]

@w0rp apologies if you've answered this before, but why do language servers need to be 'supported'? Isn't the point of the protocol that any client can integrate with any LSP? Having to manually add support brings us back to the 'matrix' problem it is trying to solve.

No disrespect, I love Ale.

[petr-k]

I guess the "support" involves invoking the particular language server daemon in the first place?

[alexcardell]

I would imagine that could be left up to user configuration by allowing us to specify the executables per language e.g. let g:ale_python_language_server = ....

[w0rp]

@Baubler Here are the important points.

1. ALE doesn't need to exhaustively list all language servers, you can define how to connect to them yourself. You can do it in vimrc, in your own plugin files, or at any other time. ALE just does that part for you, to save you the hassle of figuring out how to run the servers yourself. The top of the documentation for :help ale-lint directs you to :help ale#linter#Define(), which describes how to do this.
2. Different servers use different subsets of the protocol, and some implement the protocol incorrectly, and then ALE has to deal with those servers not implementing the protocol correctly. I think the PHP language server for some time would send diagnostics before you even had the chance to send an initialize request, and it wouldn't respond to initialize. Because people want to actually use that language server, you have to handle that.
3. Because different servers use different parts of the protocol, and the only way to accurately test different features is for people to use them, different servers require different levels of support in ALE. If a Go language server implements more completion functionality than other language server, more work has to be done in ALE to support LSP completion, and so on. The list of language servers ALE supports helps with supporting all language servers in general.

Generally, by supporting language servers, ALE actually does a better job at supporting the language servers that aren't on the list than it would if it pretended to be agnostic to how they work. It's the difference between effectively targeting something and shooting in the dark.

[w0rp]

I'll close this issue. ALE supports Pyright now, another Python language server by Microsoft for Python with type checking, and I think it's the best Python language server available.