Prevent multiple linters running for the same URI #82
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For long running linters, there was a build up LSP requests that did not clear until all linters had finished. Now the linters are running in a separate goroutine with a context that is canceled whenever a new request for the same URI comes in. This means in effect that the latest linter instance is the one returning a result.
|
Sounds good to me. Please take me a while for checking. |
|
Thank you |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I ran into an issue while running eslint on a rather large file using eslint via efm-langserver. My setup sends diagnostics requests to the langserver whenever a change is done, and eslint takes around 4s for the largish file. With the current release of efm-langserver, this means that diagnostics requests are backed up, and requests are processed in sequence, allowing the linter to finish before processing the next request. This means that for example 3 lint requests would take 12 seconds and any diagnostics requests coming in during that time would add another 4 seconds to that.
This change spawns each linter in its own goroutine, and using
context.Contexta running request for a specific URI is canceled if a new request for linting arrives.Hopefully my description makes sense!