Change:
return false; } <del> if (!this.options.textFilter) { </del> <ins> const lineMatches: IMatch[][] = []; const negate = this.options.textFilter.negate; const text = this.options.textFilter.text; if (!text) { </ins> return true; } <del> const lineMatches: IMatch[][] = []; </del> for (const line of marker.lines) { <del> lineMatches.push(FilterOptions._messageFilter(this.options.textFilter, line) || []); </del> <ins> const lineMatch = FilterOptions._messageFilter(text, line); lineMatches.push(lineMatch || []); } let sourceMatches: IMatch[] | null | undefined; if (marker.marker.source) { sourceMatches = FilterOptions._filter(text, marker.marker.source); } else { sourceMatches = undefined; </ins> } <del> const sourceMatches = marker.marker.source && FilterOptions._filter(this.options.textFilter, marker.marker.source); </del> let codeMatches: IMatch[] | null | undefined; if (marker.marker.code) { const codeText = typeof marker.marker.code === 'string' ? marker.marker.code : marker.marker.code.value; <del> codeMatches = FilterOptions._filter(this.options.textFilter, codeText); </del> <ins> codeMatches = FilterOptions._filter(text, codeText); </ins> } else { codeMatches = undefined; } if (sourceMatches || codeMatches || lineMatches.some(lineMatch => lineMatch.length > 0)) { <del> return { visibility: true, data: { type: FilterDataType.Marker, lineMatches, sourceMatches: sourceMatches || [], codeMatches: codeMatches || [] } }; </del> <ins> return negate ? false : { visibility: true, data: { type: FilterDataType.Marker, lineMatches, sourceMatches: sourceMatches || [], codeMatches: codeMatches || [] } }; </ins> } return parentVisibility; } private filterRelatedInformation(relatedInformation: RelatedInformation, parentVisibility: TreeVisibility): TreeFilterResult<FilterData> { <del> if (!this.options.textFilter) { </del> <ins> const negate = this.options.textFilter.negate; const text = this.options.textFilter.text; if (!text) { </ins> return true; } <del> const uriMatches = FilterOptions._filter(this.options.textFilter, basename(relatedInformation.raw.resource)); const messageMatches = FilterOptions._messageFilter(this.options.textFilter, paths.basename(relatedInformation.raw.message)); </del> <ins> const uriMatches = FilterOptions._filter(text, basename(relatedInformation.raw.resource)); const messageMatches = FilterOptions._messageFilter(text, paths.basename(relatedInformation.raw.message)); </ins> if (uriMatches || messageMatches) { <del> return { visibility: true, data: { type: FilterDataType.RelatedInformation, uriMatches: uriMatches || [], messageMatches: messageMatches || [] } }; </del> <ins> return negate ? false : { visibility: true, data: { type: FilterDataType.RelatedInformation, uriMatches: uriMatches || [], messageMatches: messageMatches || [] } }; </ins> } return parentVisibility;

Discussion:
It seems like attempting to filter out certain text from errors or warnings does not work. Take the following for example: Filtering to include a warning:  Filtering to exclude the warning:  I have also tried using quotes. It seems like the exclude flag does not apply to text.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.55 --- <!-- score: 0.484 --- <!-- score: 0.458 --<!-- potentialduplicatescomment --
There are a couple of issues here: 1) '!' only works with glob patters 2) 1) is currently broken
Is this going to be addressed ever? Look at this: ! Can't filter these faulty linter false idkwtf's they are, they look like it's being fed some garbage text from the linter (golangci-lint) and it contains no information, and it only shows up when I have a main package open, and I can't hide them using the filter.
Not sure how your issue is related to this. I think you should file an issue against golangci linter extension if the problems they generate do not makes sense.
Where is this issue in the backlog? It would be really helpful to clear out types of errors and warnings I don't care about with the filter so I can concentrate on ones I do care about. Thanks, Ryan
the referenced issue has nothing to do with this one (still an issue as of this date). This ticket correctly reports that the Filter's ! not operator does not work with text. Examples have been provided. This is not related to specific linters, extensions or languages. It is not dependent on whether the list is filtered by category via a dropdown or by buttons. Negative filtering Does work with filenames and paths, not with text. Examples where error is "bad statement, code BADSTMT" Filtering to see any of that text works correctly: 'state', 'BADST', ' "state" ', etc That only works when file filtering is not also applied. Example: "state" , foo. You can only have text inclusion, or file inclusion/exclusion, you cannot have both. Filtering to NOT see any of that text always fails: '!state', !BADST', !

"state" It's not globbing, these do not work either: '!bad' , '(!bad)' , '!(bad)', !"state", etc If it were globbing, there's no documented syntax to clarify whether we're filtering on text or filtering on files/folders. EDIT: Fixed formatting on wildcards
is not releated to this. This is related to the comment by
is right. The referenced issue has nothing to do with this or the situation I was talking about. Perhaps I could have been more clear in my statement, but I would like the ability to filter out types of errors or warnings, not all errors or all warnings. for example I might want to filter out all warnings about using a cmdlet Alias. It might not be best practice to use an alias, but my script will still run just fine. While testing and debugging I'm going to want to concentrate on warnings that are more likely to cause the script to fail. Maybe later once the script is working I'll want to clean up the code and use proper cmdlet names so at that time, once they are helpful, I'll unfilter those warnings.
We need to be clear and careful about exactly what we're requesting. These should probably be separate tickets: ! NOT operator on text is not working. << singular focus of this ticket -separated text and path expressions ignores the text component. refine a filter with multiple text specs. definition for And/Or logic. Syntax in this contrived example is only a suggestion: !foo AND ( "unknown" OR "missing" ) The AND and OR operators are explicit, where right now it seems the comma delimiter is ambiguous about whether it means AND or OR. sure how to filter multi-word text. Examples : , . I separate those, because while I agree with about the request, I believe he is looking for multi-condition filtering, in addition to getting the NOT operator working. If that's a concept for separate ticket, we should create it. BTW, this is not a complaint fest about filtering. The filters are greatly appreciated and this is intended as a contribution. Again, I'll look at the code to see if I can help there, but at this time I haven't looked to even see where filtering is happening.

I don't mean to confuse the issue, so I'll try to be clear as well. My request is basically a use-case example of why the ability to use a Not operator in the filters is necessary. Filtering for specific conditions or types or errors and warnings is working great and is very useful. It's just the opposite case where trying to filter out specific issues is a problem.
One very good use case is Rust (and the Rust Language Server). I am regularly getting 30-50 "found possibly newer version of crate which depends on" every time I make a typo anywhere. See for context. What's worse, Rust/RLS tries to be as specific as it can with errors, so each one of these errors is 6-10 lines long. I.e. I have to find the one actual error among 300+ lines of output every single time I make a typo. To make matters worse, RLS takes at least 30 seconds to produce this dump. That's 30 seconds waiting for RLS and 30 seconds folding errors one by one. For every typo. If I were able to filter out all the useless "found possibly newer version" errors, it would save me 30 seconds per typo. Below is an example of an actual error in a sea of noise. Notice the scrollbar on the right. !
not sure how the problems view can be helpful here. Please contact the rust extension to avoid such noise.
I did contact them. There are a handful of related bugs filed against RLS (the link in my previous post is one). And there are currently for "found possibly newer version of crate", with 7 of the first 10 being GitHub issues raised against various projects, going all the way back to 2014. So this does not look like something that will be fixed any time soon. All I'm saying is that a (comparatively) simple negative filter in VSCode would "solve" this issue and (I assume) many others like it. Also, I find the verbosity of Rust error message actually nice to have, when it's an actual error. So I wouldn't want the errors to be single line errors, just so I can more easily eyeball the one error out of a sea of copycats. Although it wouldn't be all that bad if VSCode allowed collapsing errors into a single line.

This is not an umbrella item for problems filter features. I would suggest to open a new issue for your requirements so that this item will not get side tracked.
All I was asking for was a negative filter for the Problems panel (e.g. filter out all problems containing some arbitrary substring). And providing a solid use case, by And I thought this is exactly what this issue was about. Am I missing something?
You are completely right. I am really sorry, I got carried away with the title. Updated the title to reflect the request correctly.
No worries, thanks for taking the time.
Any updates on this?
How about now? Still !working.
Back-Link for the , just because. Note: I did not found the issue here with some minutes searching, it seems reasonable to add "problem pane" to the question's title, at least that would have shown this issue in my (and possible others') search.
Just kinda bumping this issue. It would be nice.
I need this feature. I can't use VSCode because of this. My screen is constantly littered with a million irrelevant style warnings. They are distracting, unnecessary, and ugly. I cannot work with this. For the most part, VSCode with its Intellisense, code actions, problem highlighting, and its integration with language extensions is incredible. I need these features to help me code—it's why I want to use this platform. So simply switching off all error highlighting for me is not a solution. I need filtering. Extension designers add new warnings, corrections and code actions on a whim, and why wouldn't they? They want to add features and create tools that have as much functionality as possible. But because of the lack of customization on the client end, it can be incredibly annoying when this happens. You see, we as coders and (in my case, former) VSCode users also need simplicity. We want to have control over our tools. We want to code with peace of mind. EDIT: I was a bit passionate when I made this post, and I apologize for coming on so hard about VSCode which is an amazing tool—I'm in awe of the work you all do :grinning:.

In the end, I hacked my own version of the Haskell Language Server, which was the main offender—so I could use VSCode in the end!—and working with a TypeScript project, for example, is already just a dream experience. Anyhow, though I'll be very excited to see more progress on customizability, meantime, thanks for the great word done! :smile:
Would love to be able to exclude my TODO comments or move these to a new tab
Up vote this feature. It is required for the Python projects using Cython and ctypes to filter out the false no-member errors.