vscode: Clear all problems in the 'Problems' pane with a button

Please add a button in the Problems pane that allows the developer to clear all items in there.

Following discussions from #15524, #29169, #66343 and #50448.

Currently we see problems from different sources (linters, tasks, etc) and they sometimes stay there after the problem or the source file is gone, e.g. problems in an unsaved buffer, in files that were renamed, or files removed when we switch Git branches.

More often than not I have a bunch of problems and the only way to clear that pane is to restart the entire editor.

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 293
  • Comments: 139 (17 by maintainers)

Most upvoted comments

Please do NOT close this again @sandy081

(FYI @atishpatel @meshula @pmunin)

#80419 is a great example of why this issue is so frustrating. The file creates a problem which is not removed when the file is closed. The argument that it is always that it’s up to the extension providers to clear up their problems is a bit moot when the main application itself can’t even do it,

Please please please can we just have a button to clear them!

Right path is to introduce an API for problems removal and let the extensions to adopt to it. As of release, not yet planned.

@sandy081

As I mentioned in other issues, this is an issue with those extensions generating problems.

Yes. The issue is an issue from the extensions. But, adding this simple feature allows the users to have a much better experience.

Problems view by default does not show problems of a file that is not known to VS Code.

The filter probably isn’t a great idea. Plus, if you add a filter, there will need to be a way to disable it and it doesn’t catch all the cases.

I am worried to introduce a clear button because this causes repercussions like introducing API changes etc.,

Could you please explain more specifically why introducing a clear button would cause issues? The reason I ask is that there might be a difference between what you are imagining and what we are. I don’t think we need to overengineer this. Since the problems list can be repopulated by running the linters again, a clear button (or command) that would clear the problems list shouldn’t require much.

With respect 🙏

I still think that there needs to be a “Clear problems” button, but that’s a solution for me and others come from Google can see it. I want the problems gone, that clears the problems. I don’t need to hear the intricacies of your situation.

Workaround

Reload the window, it takes a second. The problems will be gone.

Screen Shot 4

@sandy081: To possibly cut through the issue:

The “Clear” button we (all) want (and which is there everywhere, in every tool, basically, but I really don’t think I need to make the case stronger for this 😃 ) would not delete “the problems” themselves, only those unwanted messages, about the problems!

When clicking that “Clear” button, we don’t actually want to delete “the problems themselves”. In our actual “problem model”, we know that problems will not magically disappear that way, all we want is to just remove the irrelevant clutter (so that we can continue working on (possibly those same) real problems).

IOW: the error messages in the panel are not the problems themselves. The messages should be decoupled from the problem objects.

(This way VSCode can keep its own problem model the way it wishes, while it would let us not be bothered with it. And if an extension wants to update those problems, new/updated message can still reappear, I guess.)

(BTW, this decoupling is actually the implicit reason, why other tools refer to that panel (i.e. its contents) as (error) “messages”, not “problems”, which I, for one, found a bit strange, when I first saw in Code. Nevertheless, it may well be an advanced concept actually, as other tools don’t usually model those problems (at least not as comprehensively). They provide messages only – and that’s pretty much all we normally need. Code should also do that, as a minimum, plus it may do advanced problem modelling, too. But doing advanced modelling instead of the usual message handling is a net loss to users, which explains the strong need for this (can’t emphasize enough: ubiquitous, kinda “standard”) feature.)

As I mentioned in other issues, this is an issue with those extensions generating problems. They own the lifecycle of problems and they are responsible for clearing them when become stale.

Looks like VS Code has to fix this as extensions are not. So here is my proposal:

  • Problems view by default does not show problems of a file that is not known to VS Code. It means if a file does not exist and is not opened in VS Code, Problems view will filter them.

I am worried to introduce a clear button because this causes repercussions like introducing API changes etc.,

Nothing wrong with an API, but it doesn’t make sense to not have a Clear button. I think as users we are concerned with practical aspects of usage, i.e. having a window not cluttered with useless junk, rather than semantic correctness on the part of extension authors we have no control over.

I understand I may be slightly off-topic, but since #50448 is locked, I share here an implementation of a task mimicking the requested feature until it is implemented:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Clean Problems",
      "type": "shell",
      "command": "echo Cleaning problems...",
      "group": "none",
      "problemMatcher": {
        "pattern": {
          "regexp": "a^"
        },
        "owner": "..." // <-- THIS NEEDS SET
      }
    }
  ]
}

The problem matcher will match an empty regex for the specific owner, which can be found as follows:

  • Right-click a problem (error/warning) in the Problems pane
  • Select “Copy”
  • Paste in a new document and get the owner of the problem matcher.

Create a different task for every owner, since ${input:} does not work with the owner field.

I was going to donate x% of profit from every project completed with visual studio code to the developers but seeing how stuborn they are with a much requested feature. I think I’d rather not thanks.

This is why we all want a magic clear button. It’s not within our power to fix Powershell, and other extensions on the vendor’s behalf, regardless on who has the moral high ground on this issue. In the mean time, we, the users, stare at clutter, with our own messages hiding in the swamp, and wish for a clear button.

A good example of why this is needed - I currently have 5 problems coming from vscode’s settings.json file which is no longer open, meaning I’ll need to reload the window to clear them.

If vscode can’t clear up it’s own problems, how can it reasonably expect extensions to do it?

Don’t let this small issue put you off - VSCode is definitely one of the better editors.

There is a simple way to clear the problems:

F1 -> Developler: Reload Window

It’s not perfect but it’s better than nothing until vscode provides a clear button. 🤞

Why is something as simple as this still open after 3 years? I would almost consider this a bug. I have errors in a file I deleted - vscode even tells me it is unable to read the file, but the item persists in the list.

Came here looking for a fix only to find that users have been asking for this for nearly 2 years. I don’t care whose responsibility it should be to clean up items in the problems window, I just want a way to clear whatever crap may be lingering there (for whatever reason, bug in the extension, deleted file, changed git branch).

Just let me clear the window, legitimate problems will reappear the next time I trigger the linter.

@adam-ah as I understand what @sandy081 is proposing the VSCode team does (I’m not part of that team), extensions might still have to be updated to consent to having their problem items deleted wholesale by the workbench when the user clicks the button.

but we’re not asking for it to magically clear the problem. All we want is a way to declutter the problems list.

The issue isn’t even just about extensions, it is not perfect problem matchers as well (and for some cases, e.g. webpack it isn’t even possible to get a PM that works in all cases) – so having a clear would be a great addition imo.

@gjsjohnmurray, we already have been through this with the conclusion that it’s not feasible to fix every developer’s plugins, but it is reasonable to fix VSCode.

If clear button is what it is needed, then we need to take the right path.

🙂 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!

I don’t understand @sandy081 , the ones we are clearing are the ones we never want to see again; the extension has long forgotten about them, that’s why they are getting stuck.

since the extension computing them might still think old problems are present

The extension doesn’t think anything at this point, the stale items have been forgotten about, the deltas are not reflecting them any more. What’s wrong with removing the stale items that the extension isn’t maintaining any more?

So if a user clears all problems he might miss out on new problems

If the extension is sending deltas, this is actually impossible as new problems will be added to deltas. How could we miss new items?

I can’t imagine that negative messages will motivate anyone. I’m also missing the feature to be able to clear the problem list.

VS Code comes for free. After ten years of using SublimeText I switched to Code approx a year ago and I’m really impressed how much it evolved since then.

It is frankly absurd this hasn’t been resolved yet

I agree with this.

This is why we all want a magic clear button. It’s not within our power to fix Powershell, and other extensions on the vendor’s behalf, regardless on who has the moral high ground on this issue. In the mean time, we, the users, stare at clutter, with our own messages hiding in the swamp, and wish for a clear button.

Regardless of whose responsibility it should be to clear out the pane, the user should be able to decide when they’ve read and acknowledged the problem to their own satisfaction, and clear the pane themselves. Sure, extension authors should be responsible for cleaning up after themselves, but they’re not doing it. Why should the users suffer when it should actually be in their control to clear that pane?

I agree that it’s not the highest priority issue, but constantly passing the buck and essentially saying, “Sorry. Not our problem. Contact the extension author.” I’m not purposely trying to ruffle anyone’s feathers, but that seems like a bit of a cop out to me. 🤷‍♂

@jon-freed my guess is that “Developer: Reload Window” is akin to you exiting from VSCode and restarting it, so I’m not surprised it clears the problems. I suggest you lobby the developers of “salesforce.salesforcedx-vscode” extension to get them to add an extra command “SFDX: Clear Problems”. It’s their extension that owns the Problem entries you want rid of.

I’m confused by this thread. I hear the maintainers saying that this is the extensions’ responsibility. But not every problem is created by an extension. I wrote a task by hand in tasks.json which has generated some problems. There doesn’t seem to be any way to make those problems disappear now without reloading the window. That seems like an incomplete feature to me.

I don’t necessarily need a nuclear “Clear all problems” button. I just don’t understand how this is supposed to ever work usefully. Can my task make the problems which it itself generated disappear somehow? I’m not seeing a way to.

Many years later, I am even more unconvinced about the “report the bug to the plugin vendor and pray for a fix” approach because new problems appear much faster than they are corrected ~ I don’t know of any plugins that I use regularly that have fixed this problem.

I pray for:

[a clear->all/clear->list of problem providers would still be as useful in 2023 as it was over 4 years ago when the issue was created]

Such a concession on our behalf would recognize the real life situation that a great many of us want to clear the panel of spam, in addition to wishing plugin authors would clean up their stuff.

Why not just be able to clear it?

On Thu., Sep. 23, 2021, 1:40 p.m. Geowan, @.***> wrote:

For those still on this issue there is an option in visual studio code where you can filter active only which only shows errors which are active. On the search section of the problems window there is a filter button where when clicked gives an option to show active only [image: filter-active] https://user-images.githubusercontent.com/20105002/134556905-fcb83ad4-cb02-47cc-95e2-b21723048c9a.png

In my case its the button next to the showing 0 of 8.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/66982#issuecomment-926021212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFKHXT6W5TAUZB6QUAZCVDUDNRAZANCNFSM4GR2Q64Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I’ve found an workaround. Solution 1 (drawback: the Problems pane gets appended with the errors/warnings of the current running task and gets cleared only at the end of task) Assign to each task the same dummy owner:

"owner": "ClearProblemsPaneWorkaround"

When executing a task, the Problems pane will be appended with the errors/warnings of the current running task but when the task is completed the Problem pane gets cleared of any previous errors/warnings and only errors/warnings of the current task remain. Solution 2 Create a dummy task to clear the Problems pane and call this before any other task. This dummy task will execute a benign command and a dummy problem matcher and so the Problems pane gets all cleared.

 {
            "label": "ClearProblemsPaneWorkaround",
            "presentation": {
                "echo": false,
                "reveal": "silent",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": false,
                "clear": true
            },
            "type": "shell",
            "command": [
                "exit 0"
            ],
            "problemMatcher": {
                "fileLocation": "relative",
                "pattern": {
                    "regexp": "(ClearProblemsPaneWorkaround)",
                    "file": 1,
                    "line": 1,
                    "message": 2,
                    "severity": 1
                },
                "owner": "ClearProblemsPaneWorkaround"
            },
            "options": {
                 "shell": {
                     "executable": "C:\\Windows\\system32\\cmd.exe",
                     "args": ["/d", "/c"]
                 }
            }
        },

P.S. I’m amazed that this clear Problems pane issue is not fixed even after all this years… and so much discussions around this issue when all of this could have been so simple.

+1 to the request Why am I not surprised to see that this was requested 5 years ago and the VSCode team just keeps ignoring it? 🤦‍♂️

To future readers: please do not post “Restarting/Reloading window fixes the problem” replies.

Those are just workarounds as the current session ends and information is lost, f.ex. the contents from the integrated terminals. I know that this may not be a problem for your use case, but it is a show stopper for others.

Problems view by default does not show problems of a file that is not known to VS Code. It means if a file does not exist and is not opened in VS Code, Problems view will filter them.

I don’t agree with this. The lingering errors aren’t always about files that have been deleted since the last check. Sometimes the extension doesn’t get executed again so the results are stale, etc. etc.

Perhaps the clear could be a forced re-run of the extension? I’m not sure if this is a good idea, thoughts?

This isn’t stale. But it is 3+ years old.

On Fri., Dec. 8, 2023, 8:09 p.m. Bob Magic II, @.***> wrote:

for the past while now i had been wondering if we were all just taking the piss on a thread nobody at microsoft knows exists and was fixed a while ago, because it has not happened in a long time here and this year i’ve done more coding than the previous.

and then today just now for the first time in 2023 the default css tools got a stuck problem in that pane about a semi-colon it was angry about. nothing would make it go away. it wasn’t even a line number that existed in the file anymore, as the file got shorter.

sigh ctrl+shift+p, “reload”

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/66982#issuecomment-1848090036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFKHXSL3H5D2WIGYV5VZ4TYIPB5XAVCNFSM4GR2Q642U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBUHAYDSMBQGM3A . You are receiving this because you commented.Message ID: @.***>

How come this is still an issue after 2 and a half years?

It is now a clear, undisputable fact that VS Code extensions are incapable of properly cleaning up after themselves, period.

This means that either someone is just not trying hard enough to work around this issue in VS Code itself, or the API is fundamentally flawed and should get an overhaul.

Sure, it’s not much fun to change an API, but such changes happen, and you did anticipate eventual API changes in its design, didn’t you? Come on, please tell me you did.

Also, how come it’s apparently not possible to work around the following cases I keep running into over and over again:

  • That file is crap. It has so many problems it really needs to be thrown away. There - I deleted it. Oh wait, the file is gone, but the problems stick around…
  • Why does this file have so many problems? Oh dang, I created it with the wrong extension. There, let me fix that… Oh wait, now I have two sets of problems, one of which will haunt me for the rest of my days.

You can’t solve at least those cases automatically?!

I don’t think that will work - for example, my problems are generated from a cmake build running as a task - I wouldn’t expect to have to open any files that have compilation errors.

If you would prefer not to add a button, or change the API, maybe just adding a command which destroys the problems window and recreates it would be enough?

Its still a problem (pun intended).

My knee jerk rxn was that there should be a way to “refresh” the problem pane thus forcing whatever put it/them there to re-evaluate the sitch and not post the problem/s again if they aren’t relevant. Nevertheless it isn’t gonna fix my “problems” right now and it’s holding up progress.

(Not sure whether this or #50448 or some other item is the correct place for this comment)

Current workaround: command “Developer: Reload Window”

Another use case for such a “Clear problem(s)” button or command is this:

The extension “salesforce.salesforcedx-vscode” enables a command and a context-menu command “SFDX: Deploy This Source to Org”. You can use the command from the Explorer window/pane without even having a file open. If the deployment fails, a “Problem” line will be created. It will go away if you can successfully use that command to deploy that same file, but that isn’t always desirable. The current work-around is to do the “Developer: Reload Window” command. But that’s quite drastic.

Count me among the people who think a user should be able to clear the “Problems” view/pane like the Output, Debug Console, and Terminal views/panes can be cleared/killed. I did read @sandy081 / @dbaeumer 's comment(s) why “Clearing problems is not as straight forward”, and I still feel (subjectively and perhaps naively) that ultimately, a consistent experience across the views/panes is better. If the problems did not go away upon the “Developer: Reload Window” command, then I might feel differently. But they do.

for the past while now i had been wondering if we were all just taking the piss on a thread nobody at microsoft knows exists and was fixed a while ago, because it has not happened in a long time here and this year i’ve done more coding than the previous.

and then today just now for the first time in 2023 the default css tools got a stuck problem in that pane about a semi-colon it was angry about. nothing would make it go away. it wasn’t even a line number that existed in the file anymore, as the file got shorter.

sigh ctrl+shift+p, “reload”

which is a double pain in the arse because im using the remote dev stuff so its a full state wipe and connection reconnect, one being suffered just to sanity check the problems pane against what i think of the file. so now i lost my up arrow history in that terminal from the reload, and like now im really feeling that burn in the tips of the ears right.

can we just have a button?

Had this problem again, editing validated JSON with a schema is a very negative experience. It’s affecting my productivity 😦

I can’t believe after this being constantly requested for so many years. They still haven’t done anything and are being so stubborn about it. It just makes the developers look really bad.

I’ve raised one, but the bug isn’t really the issue…

perhaps those who want a clear button could collaborate on an extension.

so, every user who suggests something to improve VSCODE have to program an extension by himself or must collaborate on it… ok.

every vscode user needs to know javascript… if not I think he shouldn’t download this software.

re @dcsan my experience is that it works like, 1.4% of the time.

Hahaha 😆 Yeah, it’s not an ideal solution, but it’s about what I do to solve it currently with “Reload window”. 😃

So, where do we stand? There have been 5 issues opened with multiple people commenting and the proposed filter solution won’t work in many cases. What more would it take to decide if a proper solution with an API change should be implemented? Or should we just live with the reload window?

+1 to the request Why am I not surprised to see that this was requested 5 years ago and the VSCode team just keeps ignoring it? 🤦‍♂️

Ha, I just swung by see if there was any resolution for this yet, or if anyone came up with any hacks or workarounds.

I gave up on that useless window, and I’m just running watch 'ninja 2>&1 | head -n50' on a terminal outside vscode. The C++ Intellisense just does not clear. You can never be sure that the message there is old or current.

I think it’s reasonable that, as a user, if there is a problem (from tsc, or other tools, language servers etc) with a file, and I delete the file, the problem for that specific file should be refreshed and should be gone.

I’ve had a file deleted over 2 days ago in my VSCode and the TypeScript language server still has a problem listed for it.

Edit: My current workaround is to run the TypeScript: Restart TS server command

For those still on this issue there is an option in visual studio code where you can filter active only which only shows errors which are active. On the search section of the problems window there is a filter button where when clicked gives an option to show active only filter-active

In my case its the button next to the showing 0 of 8.

perhaps those who want a clear button could collaborate on an extension.

@fregante not trying to be negative or pile on, but what you’ve proposed is not a “solution” – it’s a poor workaround at best. The point of this thread (and most on GitHub) is to find a real, permanent solution that deals with all or most cases.

This particular problem is obviously hard because there are 2 major camps along 2 dimensions: 1a) those who think problems should apply to open files 1b) those who think problems should apply to all files in whatever the notion of folder/project/solution is.

2a) those who think problems should be tracked by their source and removed as soon as they are resolved 2b) those who think problems should be emitted to the problems pane and then forgotten by their source

until we resolve these fundamental divides in the community – or resolve to support multiple paradigms, we will never please everyone.

in the mean time, work arounds are fine – but they should be identified as such. not called “easy solution” when they are far from that.

bad solution and it takes way more than 1 second if you’re using the remote development extension pack but thanks for playing i guess.

Has any progress been done towards this? I see many people have such problems https://github.com/rust-analyzer/rust-analyzer/issues/5446 https://github.com/vshaxe/vshaxe/issues/132 etc., but no progress has been made here in a very long time.

Lmao, can you link to said paper @bobmagicii?

https://github.com/microsoft/vsmarketplace/pull/875 this md file they are collabing on.

I’m thoroughly amazed at the reaction by vscode developers. I’m surprised UX isn’t higher on the list of priorities.

@HFTrader FWIW, the default binding to go to the terminal is Ctrl-`. No shade for preferring your terminal outside the editor, but it’s not hard to get to by keyboard.

I think the reason this issue is stalled for years is that there’s something fundamental about the vscode architecture that makes it really hard to actually clear problems without handshaking the problem-generators.

As a solution to avoid needing to touch deep magic in vscode, what if problems individually had a visibility flag? Then we could break the logjam with a “Hide all problems”, or “Hide selected problems” button, and a “Show all problems” button. There’d be no need to rearchitect things, and users would get control over the ability to view and prune the list in a way that supports their workflow. There could even be a little indicator on the Show all button, like [ Show All (+15) ]

Aside from the addition of a single flag to a problem record, I would expect the impact on everything code-wise to be minimal, and I expect that it would satisfy the user need to visually clear the panel to support workflows where from a user perspective it is important to be able to visually clear the panel.

i completely agree that each extension should clean up after its self. but when OmniSharp can’t even do that, you got problems.

Wow, I can’t believe there is no mention of this but if you’ve made your own problemMatcher in tasks.json and errors/warnings stay after a rebuild, make sure you also set the “owner” as mentioned here https://github.com/microsoft/vscode/issues/66982#issuecomment-1042698569

For the extensions API, I would just introduce a vscode.workspace.onDidClearProblems or vscode.workspace.onDidRequestReinitialization and let extensions opt-in to clearing/reinitializing whatever problems they created. I think it is a natural lifecycle event that some change made outside the extension’s environment, can/must trigger reinitializing. If you can’t “trust” the contents of the problems tab because items are stale, then you stop using it (I have). If you had done something like that when this feature was requested, it would probably be implemented in most places by now.

I get that it is not as simple as removing them all forcefully, as the extensions would have no way of determining if their state (what problems it assumes are currently visible to the user) had become dirty.

Wow!! looking at the logs for this issue, this is a feature that has been requested time and time again for many years. But, for some reason, adding new telemetry or new tools is more important. ¯\_(ツ)_/¯

I’m also linking issue #63244 because it seems to have not been linked to this one.

Dare we look at Webstorm/IntelliJ for prior art? There is a button to clear the pane. That’s it. There aren’t any camps or dimensions. @fregante - I appreciate your workaround and your comment is on the money.

why I must reload the entire IDE to clear problems in single tool tab?

The problem with reloading the window is that you lose your undo history.

idk if this is the right place to post this, but… I realize some people prefer to only see problems for open files, but it is critical for some projects / types of projects to see ALL problems across ALL files regardless if the file is open in an editor or not. I also realize this can be a performance issue at times, but I would gladly sacrifice some performance for guaranteed knowledge of ALL problems, as the bar for many of my projects is 0 errors / 0 warnings. I just ask that this be kept in mind whenever the design of new Problems pane features/API’s are considered.

Yes, definitely was reported and said to be a vscode not extension problem…

@Spongman has this been reported to the extension author? That is where it needs to be fixed.

good question, has it?

it seems to me that the initial request has merit regardless of whether or not the various extensions mentioned above have bugs. the other panes (output, debug, terminal) all have ‘clear’ menu items. the fact that the problems panel doesn’t seems unorthogonal. i’m sure there’s really good reasons for this due to the extension api design and the extension implementations, but as a user i really don’t care. i just want to clear the panel.

This is easily reproduced. Open a powershell file with errors in it and close it. Open another ps1 with no errors. All the previous errors are still in the problems pane. it’s clutter! Don’t need it. My mind is already cluttered with junk. WTF!!!

For those waiting for a feature like this – please take a look at https://github.com/microsoft/vscode/issues/51103 – adding support for filtering problems by the extension which generated them.

If you’re trying to temporarily ignore issues generated by noisy extensions like spell checkers, formatting extensions, etc. (e.g. especially when working on a quick patch for an open source project) that feature might be what you’re looking for.

It just needs a few more 👍s to get into the backlog.

It would be great to have a clear button. But here the issue seems similar to twitter fight for an edit button 😅

Facing this now with Git History plugin. When I view a git history, issues appear in Problem view. And, no way to clear these. A Clear button would be nice. Most IDEs do this.

@adam-ah If a clear action is introduced, then it cannot be specific/scoped to stale problems. A stale problem can be anything in the given context. It can be from the deleted file, or from a task which did not update on fixing the problem. My point is that, clear action cannot be half complete and it should work for all problems including those which behave correctly. It means that extensions that are playing well and smart (incremental) should be aware of problems being removed.

If the extension is sending deltas, this is actually impossible as new problems will be added to deltas. How could we miss new items?

It is not just about missing it is also VS Code and extensions will be out of sync. This is not a good design and is error prone.

What if the button cleared the list AND restart extensions that contributed to the problems list? This would allow for no delta issues and in turn, no missing out on problems. Is there a reason why this can’t be done or why the solution is bad?

It is not good to restart an extension to just reset the problems. An extension can be contributing more in addition to problems. This should be called restart extension instead of clear problems 😄 . Anyways restarting a running extension without window reload is not possible due to code loading and unloading. This is a separate topic and let’s not deviate. If clear button is needed, it has to be done the right way with API.

@sandy081 Ah, thank you for quoting that. It helps us understand and focus on potential solutions.

A couple of questions:

  1. As adam-ah said, why wouldn’t extension know the deltas is all problems? Are the deltas stored by the extensions instead of by vscode?
  2. One option is to introduce an API change that notifies the extensions, but there are other options. I’m currently solving the problem by using the “Reload window” command. What if the button cleared the list AND restart extensions that contributed to the problems list? This would allow for no delta issues and in turn, no missing out on problems. Is there a reason why this can’t be done or why the solution is bad?

Clearing problems is not as straight forward as it is. @dbaeumer mentioned why exactly it is here

In VS Code problem model problems are owned by the one creating them. An extension could therefore always only apply the delta (e.g.remove one and add another one) instead of always computing all errors and pushing them into the model (the task system by the way does some delta optimizations as well). So if a user clears all problems he might miss out on new problems even if he changes files since the extension computing them might still think old problems are present (for example during incremental builds).

So, this needs introducing API(s) for changing problems and this has to be adopted by the problems owners.