Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Location List Doesn't Close After All Errors Have Been Addressed #2460

Closed
jfelchner opened this issue Apr 27, 2019 · 7 comments
Closed

Location List Doesn't Close After All Errors Have Been Addressed #2460

jfelchner opened this issue Apr 27, 2019 · 7 comments
Labels

Comments

@jfelchner
Copy link

jfelchner commented Apr 27, 2019

Information

VIM version

NVIM v0.3.4
Build type: Release

Operating System: macOS 10.14

What went wrong

I have an error in my file, which shows up in the quickfix list. I fix the error in my file. ALE does not auto-close the location list once the error has been corrected.

Additionally if I have an error, then close the location list, ALE opens the location list again, shows the error, runs the checks, then leaves me with an empty location list.

a) The location list should not reopen until ALE is sure that there are errors remaining in the file after the checks run.

b) We need a way to auto-close the location list if there are no more errors after checks. The QuitPre autocommand only works if you're closing the buffer, which I am not.

Reproducing the bug

See above

:ALEInfo

https://gist.github.com/jfelchner/77a37bde7fdff2275f1c5bf7252b30e8

@w0rp
Copy link
Member

w0rp commented Apr 27, 2019

It's supposed to do what you describe. Let me know which linters you were using, as the :ALEInfo output there seems to be for another buffer where no linters are enabled.

@w0rp w0rp added the triage label Apr 27, 2019
@jfelchner
Copy link
Author

@w0rp I updated the gist

@CorbanR
Copy link

CorbanR commented Apr 28, 2019

I am experiencing the same issue

** UPDATE **
Not 100% sure why, but the solargraph gem is what appears to be causing the issue.
When I remove the solargraph gem(all versions) ALE works as expected and closes the window when all issues are fixed.

NVIM v0.4.0-1240-ga3d8cd3f6
Build type: Release

:ALEInfo
https://gist.github.com/CorbanR/0ed4833d9e3dd836a904a77559a629b0

Relevant .vimrc config
https://gist.github.com/CorbanR/2a57a7e0fa7beb1ef33506cff575c366

Screen Shot 2019-04-28 at 2 03 51 PM

Screen Shot 2019-04-28 at 2 04 19 PM

@w0rp
Copy link
Member

w0rp commented Apr 30, 2019

This was probably caused by #2415. git pull and try it again. If the issue persists, debug it and submit a patch for it. I can't repeat the bug myself.

@CorbanR
Copy link

CorbanR commented Apr 30, 2019

Thanks for creating this plugin w0rp, Ale is srsly amazing.
Still appears to be an issue. Again, it seems tied to solargraph being enabled as a linter.

When solargraph is not loaded as a linter it does NOT seem to be a problem.

let b:ale_linters = {
\    'ruby': ['brakeman', 'rails_best_practices', 'reek', 'rubocop', 'ruby', 'standardrb']
\}

Ill try to debug it a bit more and see if I can figure out a root cause.

@w0rp w0rp closed this as completed in eae124e May 1, 2019
@w0rp w0rp removed the cant repeat label May 1, 2019
@w0rp
Copy link
Member

w0rp commented May 1, 2019

I have fixed this now. The problem was specific to only Language Server Protocol. The problem is that it's impossible to tell if a language server will respond to a file changing or being saved with diagnostics, so ALE can't keep track of if results are pending from language servers, as they may never arrive. ALE does this reliably for tsserver, which requires an explicit message to request diagnostics, and which always returns a response for that message. ALE was using that information for determining if the location list window should be closed, to prevent it from popping open and closed too often. (Which for regular command line linters is very annoying.)

I have created an issue for the protocol here. microsoft/language-server-protocol#737 I think the protocol should be updated to support a mode which means that diagnostics are only sent to clients that explicitly request them, for a number of reasons.

@jfelchner
Copy link
Author

@w0rp I just tested and it's working great now. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants