Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Linter markers become inconsistent after edits, during linter running #1404

Closed
atombender opened this issue Dec 12, 2017 · 3 comments
Closed

Comments

@atombender
Copy link

atombender commented Dec 12, 2017

My machine is being sluggish today (Gometalinter even more so) for inexplicable reasons, making some flaws in the linting more apparent. The most immediate problem is that markers stick around while the next linter run is executing, but even worse is that their positions become invalid. Here's a video with me fixing an unused method (gzipped MP4 video):

  • I hit "next marker" to highlight the first one.
  • I hit escape to stop highlighting it.
  • I remove unused1.
  • I hit "next marker". The marker for unused1 is shown, even though the marker is for a line that no longer exists.
  • I hit "next marker". The marker for unused2 is highlighted, but it's at the wrong line.

So the line tracking here is really bad. If I remove a line, any markers below should be moved up.

In my opinion, linter markers should be removed while the linter is running, because they are probably wrong.

Also it's obvious that there's no visual feedback to indicate that linters are running, so I don't know if markers are forthcoming. I don't know if VSCode has any way to show any progress information here without being too intrusive.

@ramya-rao-a
Copy link
Contributor

In an ideal world, there would be a linter running on each file edit (without waiting for a save) and all markers would be up to date. Unfortunately for Go, we can only have the linters run on save. So trying to get the markers match with the right line before the triggered linting is complete is not possible.

Currently, the markers are cleared after linting/building is completed. When these processes are slow, edits and further saves cause the above mentioned issues.
I pushed a change to clear these markers on file save. This will ensure that the old diagnostics are not reported against newer edits.

There are ways to show progress. Either via a status bar item or a blue bar going from left to right at the top. I am a little hesitant to add the latter. In worse case scenarios, you will always end up seeing them. A status bar item is do-able, but naming it right is tricky. Because ideally you would want to track the progress of build, lint as well as vet

@ramya-rao-a
Copy link
Contributor

In the latest update to the Go extension (0.6.70), buid/linting/vetting errors will be cleared on file save to ensure slow linters/vet doesn't result in stale diagnostics

@atombender
Copy link
Author

Thanks, @ramya-rao-a!

@vscodebot vscodebot bot locked and limited conversation to collaborators Feb 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants