hsanson
commented
1 year ago Nice work. Some thoughts from a quick look into the problems your describe:
Problem 0: inverted socket logic and unclear lifetime.
Not much we can do on ALE's side but the wrapper script you implemented is a good work around. Better would be to have sonarlint be changed to create and listen to the socket insted of expecting one to connect to.
Problem 1: missing clientInfo
From the spec (see initializeParams) I see the clientInfo is optional. The correct thing to do here is to have sonarlint consider it optional.
On the other hand adding it to ALE should not be difficult. See ale#lsp#Register() function in ALE's source code.
Problem 2: missing window options
This is also optional (see clientCapabilities) but adding it to the initializeParams ALE send should not be difficult.
The problem with adding initializeaParams is that it may cause other LSPs to behave in ways ALE is not expecting. This would need to be tested.
Problem 3: ALE not responding to config request message
ALE explicitly sets workspace.configuration capability to false when initializing the LSP. In this case the LSP should not be sending workspace/configuration requests to the client since it is telling the server it does not support it.
On the other hand adding support for this maybe is not too complex. We would need to change the s:SendInitMessage() function to set workspace.configuration to true and then add a handler for the workspace/configuration method in the ale#lsp_linter#HandleLSPResponse() method.
Again changing initialization parameter can have undesired effects on other LSPs so this must be carefully evaluated.
Problem 4,5: Proprietary extensions
Proprietary extensions are not unheard of and ALE supports some (e.g. eclipse jar extensions). Sonartype should define client capabilities for these extensions and do not send them to the client if they do not explicitly advertise support for it.
Problem 6: SonarLint diagnostics making Vim hang for a while
Since LSP is handled asynchronous I would not expect Vim or Neovim to hang on this situation. In any case adding the filtering itself in ALEs LSP response handler should not be an issue.
These are some observations from a quick look at the issues you describe. Please do not take any as granted since my experience with LSP in general and ALE's implementation is basic at best.
mMontu
Jorengarenar
Name: SonarLint URL: https://www.sonarsource.com/products/sonarlint/
SonarLint is not working out-of-the-box with ALE. Therefore, I have made some investigation and even a simple prototype to make it work: https://github.com/burrima/sonarlint-ls-wrapper (works with C++ and Python).
There was also some prior discussion taking place on the Sonar community forum: https://community.sonarsource.com/t/running-sonarlint-language-server-from-shell/24440
I don't think this is purely an ALE issue, SonarLint should also get some "fixes". ALE is generally not supporting all features of the LSP protocol. Most importantly, it does not expect requests sent actively by the language server. On the other side, SonarLint is using some proprietary features, which is also not nice. There is no possibility in ALE (at least not from what I've seen) to reply to these proprietary requests (e.g. by linter integration script).
Would be nice to hear from you (the maintainers of ALE) if you generally like the idea of integrating SonarLint. I am also reaching out to the SonarLint developers with the goal to enable a collaboration between people of both projects - if there is interest from both sides.