Filter "Problems" by the extension which generated them (Markers Panel Filter)

[bitjson]

I'd love to be able to declutter the "Problems" Markers Panel by hiding/showing logs generated by only certain extensions.

Right now, if I type [ts] into the filtering box, I get No results found with provided filter criteria. Clear Filter.

If I then delete the filter, I can clearly see plenty of warnings and errors generated by [ts]. After tinkering with it for a while, I've not been able to figure out how to filter by the extension name. (Maybe it just needs some documentation or UI to help the user write filters?)

Also, for other users finding this issue, after a bit of searching around I realized I could also filter roughly by using the keywords warning, error, and info. E.g: enter warning, error into the filter to hide info markers. This helps a bit, but doesn't help much when you're trying e.g. to filter out a particularly noisy extension (like a spell checker) generating the same type of marker you're looking for.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Feature Request: allow extension filter exclusions (#26988)
• Test Ignore Folder/Files in Problems view (#48390)
• Feature request: filter on Explorer (#26188)
• Problems: Changed "Filter by type or text" to "Filter" (#46865)
• Problems: Improve filter text (#8305)

[bitjson]

(Reviewed, none of the above issues address this particular problem.)

[sandy081]

Related #8305

[graph]

I would like to add when filtering problems also update which files are highlighted. All my files are always red because of spell check plugin. Sometimes I don't care enough to fully setup the C++ plugin and I get errors everywhere because of missing includes. I would also like to ignore all those and only see actual errors produced when compiling.

Maybe a simple list of plugins with a checkbox beside it so I can uncheck which plugins output I currently don't care at the moment.

[barakbd-bluevine]

Exactly the same request as @graph - I want to hide spell check from the problems panel (But I woul like to highlight them inside the files)

[lygstate]

+1 for filtering problems generated by specific extension

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[HenokAddis]

This work got moved to the backlog, but is there a target release? Can me and my team help support this work with developer resources? Who should we reach out to for design discussions before we begin investing here?

Many of the above comments echo the pains our customers are facing as well. In addition, it would be even better if a user could be given pre-defined filters for "Owners" or "Sources" that exist in the problems pane so they can filter to the issues they wish to investigate easily.

For example, the spellcheck scenario where there are many instances of spelling issues makes it difficult to investigate errors in the build. Filtering the problems pane down to only the build errors would allow a user to investigate more efficiently. This could be done by selecting the "Owner" or "Source" (still not clear which is correct) of those Build errors through a dynamically generated list of filters for convenience.

This same scenario can be applied to any warning or error in the problems pane.

[emmenlau]

For spell checkers this is a very relevant issue. The extension provides important help when writing, but for most programming tasks it clutters the "Problems" pane unnecessarily.

[GitMensch]

With the recent addition of negattive text filtering #115351 it is at least possible to "fake" that (for a single extension) as long as it leaves a correct source hint: ![ts] filters those out also similar possible: ![cSpell].

[stephenmartindale]

The negative text filters proposed by @GitMensch did not work for me (in code 1.83). Instead, filtering without the brackets was necessary: e.g. !cSpell

[pknowles]

As a workaround for C++, adding the option "C_Cpp.errorSquiggles": "disabled", cleaned up a all the spurious intellisense errors and mostly left me with real compiler errors after building. Guessing clangd/vscode-clangd#114 might work for clangd.

[black-puppydog]

filtering without the brackets was necessary: e.g. !cSpell

+1 from me. filtering with [] didn't do anything.
But even with negative filtering this doesn't do what I want. I want to only display problems issued by the typescript type checker. Filtering by name works for pretty much any other source of problems. Ie I can filter for "eslint" and that will be reasonably accurate. but filtering for "ts" doesn't help at all because (surprise!) all my files end in .ts. 🤦🏽

[digiexchris]

this is very relevant for embedded programming with toolchains that intellisense is not fully compaitible with. I still use intellisense for navigation and code completion, but it's incorrect about not being able to find some sdk functions that I'm using, so on a clean compile I get a few hundred erroneous "problems" popping up post-build. And when I have a legitimate problem, that window is useless because of the false positives. If I could exclude intellisense from the problems window, that would be bloody marvelous!

[gulshan]

The error/warning view needs an overhaul to improve the DX. I would request to make this "problems view" a combination of table and tree views. Then make the group by, sort by and filter by options controllable by the user. And each of these "_ by" operations should support multiple parameters. Then one may group the problems by source extension and file, then filter by source path and then sort by the message. Or any other way that suits the user.