3 ms·

Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "prev

Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "previous marker" so I can jump to the next problem. They don't work across an entire workspace, sadly, and I have an outstanding Github issue about it that has not seen any activity for years. Project-wide linting is something that VSCode really lacks right now. For example, it's easy to change something in one file that breaks another file, but you won't get any error markers until you go to the broken file.

jamesgeck0 9y ago
> Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "previous marker" so I can jump to the next problem. The ESLint plugin does both these things; linting is just an example. I use the terminal's click-to-open file feature for opening files that have have merge conflicts during git rebase, and for opening spec files that failed. It's just handy to have.