WIP Fix 1996 - Add eclipse LSP support.

[hsanson]

Adds support for the eclipse language server that seems to work better than javalsp for gradle and maven projects.

Closes #1996

[w0rp]

Should be good once this is ready to go.

[w0rp]

I opened an issue for supporting command_chain for LSP linters. See #2128.

[w0rp]

This PR is blocked by #2132.

[w0rp]

@hsanson I finished work on #2132 last night, so now you can replace the system() call here with ale#command#Run. Have a look at the documentation for the function and existing uses in the codebase. You can effectively run the command in the background and receive the results in a callback, which can return the command to run for starting the language server.

[w0rp]

You might also want to try using the internal ale#semver#RunWithVersionCheck function, which uses ale#command#Run to parse semver versions from results and then cache the results so we only need to run the version check roughly once per executable.

[hsanson]

@w0rp first let me say, great work. I did not think this refactoring could be done so fast.

Have modified the Eclipse LSP to use the new async callback methods following as example the flake8 linter. Also with caching of versions similar to ale#semver#RunWithVersionCheck.

But I have one test failing it travis CI that I am unable to pinpoint. I am sure I have listed the new LSP support everywhere it should (ale-supported-languages-and-tools.txt, ale.txt, and supported-tools.md).

Also I don't see the LSP being invoked in ALEInfo as before. I can see version checking is being executed but no LSP.

And since a while back I am unable to get auto-completion working with any LSP, including this one. When time allows it, please check this MR and let me know if you find what I am doing wrong.

[w0rp]

The test is failing because something isn't sorted correctly in the documentation.

I don't know why the command isn't being run on your machine. I'll have to try this linter myself on my own machine, at some point.

[hsanson]

Fixed the sorting issue with the list of supported tools.

Using the ch_logfile trick in vim it was easy to find the issue with the LSP server:

  9.856030 on 0: Freeing job
  9.856536 RECV on 1: 'Error: Unable to access jarfile /home/ryujin/Apps/eclipse.jdt.ls/org.eclipse.jdt.ls.product/target/repository/plugins/org.eclipse.equinox.launcher_1.5.200.v20180922-1751.jar
'

In ALEInfo there are no details of the LSP errors. Without the ch_logfile in vim is not possible to know if there are any errors. In neovim this is what I see:

let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
  Command History:
(executable check - success) java
(finished - exit code 0) ['/bin/bash', '-c', '''java'' -version']
<<<NO OUTPUT RETURNED>>>

Is there a way I can make any errors reported by LSP appear as part of ALEInfo output?

Apart from the above I think this LSP can be used.

[w0rp]

See #2137 for adding LSP debugging information.

[w0rp]

Cheers! 🍻 Thank you for working on this, waiting for a few months for me to get the uniform asynchronous API done, and then coming back and finishing this.

[JulioJu]

@hsanson maybe in the ALE documentation, it could be cool to explain shortly how to customize compiler warning / error preferences ? We should add customization under root_project/.settings/org.eclipse.jdt.core.prefs with values presented at https://help.eclipse.org/neon/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html ?

What do you think about that ?

[hsanson]

@JulioJu sounds interesting but I have not used this feature and cannot see it documented anywhere on the eclipe lsp repo. Is this a known feature? I do not want to document something that is internal and may change in the future.

[JulioJu]

@hsanson you could check eclipse-jdtls/eclipse.jdt.ls#581 . See also for the future redhat-developer/vscode-java#507

[hsanson]

From the issues linked above I see:

We do not have a proper way of defining those yet. unofficially though defining them on an eclipse style .settings/org.eclipse.jdt.core.prefs should work for now.

Once eclipse.jdt.ls has official way to add preferences that is documented I will be more than happy to add a note with a link to the official documentation explaining how to set them.

Of course anyone is free to modify the documentation and submit a MR for review.