You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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
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
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):
unused1
.unused1
is shown, even though the marker is for a line that no longer exists.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.
The text was updated successfully, but these errors were encountered: