Clear problems using a task

[tksuoran]

Is there any other way to clear problems window, other than using "Reload Window" command?
I would like to perform this from a task. My tasks generate new entries to problems, and I would like to clear the old problems first.

[vscodebot]

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

• Task>Presentation should allow to clear the terminal output. (#30058)

[dbaeumer]

There is not need to do this. VS Code does it automatically. Do you have steps where this doesn't happen. Please note that VS Code only does this for problems captured by a problem matcher for each task. So if you have two tasks with two different problem matchers running them only clears the onces belonging to the matcher.

[tksuoran]

I have several dozen tasks and together their problem matchers have thousands of hits. I do need to clear problems between tasks in order to be able to examine problems of a specific task.

Alternatively it would okay if task/problem matcher could associate a "code" and problems would group issues with this code and I could fold/unfold groups individually.

[Tallyb]

Some examples of non clearing problems:

• problems pointing to a deleted file.
• Problems pointing to a gitlens revision file

[dbaeumer]

@Tallyb both of these kind of problems should be removed by the one creating them in the first place either when the task is rerun or in a case of watching when the file events are sent out.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[aaroncraig10e]

This is a prime example of a developer deciding for the community what best practice is, and it's horribly arrogant and frustrating.

VSCode should not dictate any given workflow. It should support my workflow, because as an intelligent engineer, I know the best workflow for my use case.

Refusing to add what must be a trivial feature simply because you as the maintainer of the project wouldn't use such a feature smacks of an elitism that has no place in this community.

This attitude ruins an otherwise amazing package, and frankly leaves me wanting to look elsewhere for an IDE merely on principle.

The fact is, there are many legitimate use cases for ignoring errors at any given time, all of which have been listed either here or on one of the other issues raising this problem:

• I've closed those files as they do not impact my current task
• They are errors that I cannot or do not want to fix in the present moment
• They are not errors, because the offending file has been deleted

In each of these cases, the stale error output in the problems pane creates noise that makes it hard to find my actual issues, creating a frustrating user experience. Reloading the window has a workaround is not a real solution -- depending on the plugins installed, startup may take many seconds (or minutes) to index files, etc.

Please add this simple feature!

[dbaeumer]

Closing the issue was not an active developer decision. The issue got closed because we have ask for more information / reproducible steps to better understand what is happening and if that information doesn’t arrive in 14 days then our bot closes the issue automatically (for more information about how we do issue management pls see)

In this particular case some information was provided and we should have dug deeper to better understand what is frustrating by asking for a better example of what tasks are executed to find a solution to solve @tksuoran´s problem.

In general if something like this happens it is enough to send a ping by adding a comment in the issue and ask what information we still expect.

[dbaeumer]

@tksuoran understanding your use case correctly you want to do something like this: specify in a task which problems from other task runs should be clear when this task is executed. Something like:

{
   "label": "TaskA",
   "command": "..."
}
{
   "label": "TaskB",
   "command": ".....",
   "clearProblems": ["TaskA"]
}

[tksuoran]

I have couple of dozen tasks. These are reports from different static analysis rule checkers. Together they report thousands of issues spread to a large codebase. Some of the reports contain hundreds of issues, some report only few or just one.

I want to examine these reports one rule at time. So when I execute a task to view such report, I want to throw away all other reports. So in my case I would like to use wild card or some other way to simply throw away all previously shown issues.

[aaroncraig10e]

Just wanted to keep this alive.

In the latest version of VSCode (I'm on the nightly builds) the problems pane behaves pretty well, except for when I close TS files that have problems.

For example, if I have a file open which contains linter issues as reported by eslint, closing that file causes those errors to disappear from the problems window.

However, if I have a TS file with [ts] issues, closing that file does not cause the errors to disappear from the log.

I understand the reasoning that the problem pane's output should be fully controlled by whatever processor is triggered by a given file, so would this behavior be better reported to the TS linter?

[dbaeumer]

@aaroncraig10e no, since TS is following the recommendation of VS Code. Compiler / Linters that have a project concept and inter file dependencies are asked to keep problems around even if the file is closed. The reason is that a problem in file A.ts can be fixed by changes in file B.ts. If the problem would be removed if A.ts closes the user had no indication that his change in file B.ts actually fixed the problem.

[aaroncraig10e]

@dbaeumer, this makes a lot of sense for the case that you describe.

How do we deal with cases where the errors in file A.ts are scoped to that file alone? Or if I've closed all the files that A.ts is related to? In that case, the only way to get rid of the error message is to restart VS Code or else fix the errors, which may not be something I plan to do in the current work session.

Which brings us full circle to the original feature request, which is a way to clear the problem window buffer so as to remove noise (from the point of view of my current session).

It is admittedly a tough UX to design, full of edge cases, and one could argue that there is already an ability to clear the whole pane, which is to reload the app. Certainly having a button to clear the window, while an imperfect solution, is better than reloading the entire app.

[aaroncraig10e]

Just ran across another significant scenario -- switching git branches. In this case, I end up with errors being reported for inexistent files.

[dbaeumer]

@aaroncraig10e this clearly sounds like a bug for me. Can you please open a separate issue so that we can track and fix it.

[Gruntfuggly]

I've got a situation where a file has generated errors. I've closed that file so it is no longer shown in the editor, but I still have 120 errors in my problems window. I understand that the devloper of the linter should be responsible for clearing these up, but if they aren't or there is a problem with the linter (or extension) why do I now need to reload the window and lose my undo history, etc.?

The amount of discussion (and resistance) around clearing the problems window seems absolutely ridiculous to me.

Can we please just have a button or a command to clear the problems window?

[dbaeumer]

@sandy081 do you have an issue for this for the problems pane.

This issue is for clearing problems using a task run which in @Gruntfuggly use case will not help.

[Gruntfuggly]

The reason I added my case here is because the other threads have been closed or locked.

[bobbrow]

I actually don't want the TS extension to show problems for B.ts if I never opened it. I will wait for the compiler to tell me something is wrong. Likewise for C++, it would be too expensive for us to lint every unopened file in the workspace if a user made a change to A.h which negatively affected some B.cpp. I let the compiler tell me when I break something. This is the equivalent experience I am used to in Visual Studio.

We only had orphaned problems when there was a bug in our extension. We fixed those issues and our customers are happy now. This issue has only come up because one of our customers now wants us to leave squiggles around after closing files which is when I noticed the functionality change with TS.

I'm fine with exposing a setting in the C++ extension that lets us control whether problems persist after closing files, but I think the setting would more appropriately live in VS Code. Either way, based on the feedback we've received and my own personal opinion, I would not recommend this behavior be the default.

[dbaeumer]

I actually do want a tool to show me errors as soon as they come into existence not only after a build :-).

[bobbrow]

Unfortunately, that is impossibly expensive for the majority of C++ projects. In addition it would be overly noisy while I am in the middle of editing code (e.g. the linting kicks in while I have a mismatched curly brace or am refactoring a class and suddenly 1000+ problems show up across all files in the project).

In my opinion it makes more sense to let the user decide when is the appropriate time to rescan the entire project (e.g. when I'm ready to compile it).

[dbaeumer]

Unfortunately, that is impossibly expensive for the majority of C++ projects.

I can see that this is challenging for C++

In addition it would be overly noisy while I am in the middle of editing code (e.g. the linting kicks in while I have a mismatched curly brace or am refactoring a class and suddenly 1000+ problems show up across all files in the project).

Good compilers handle these cases nicely by only checking or showing sematic errors if there are no syntax errors.

[bobbrow]

Good compilers handle these cases nicely by only checking or showing semantic errors if there are no syntax errors.

Sure, that handles the mismatched curly brace case, but not the case where I'm cutting and pasting variables/full functions/classes, reordering arguments, or other syntactically correct but semantically incorrect refactors.

Not even TypeScript turns off semantic errors for syntactic errors though, so it would seem that this is more challenging to implement than it sounds.

[developer1011]

Currently the only workaround is to use the 'reload' extension
https://github.com/natqe/reload

[felix9]

Repro steps:
I have a typescript project with one tslint error.
I do Terminal->Run Task.. "npm lint", which runs "tslint" (v5 output)
The Problems pane shows the one lint error.
I fix the lint error and save the file.
I repeat the Run Task.
The terminal shows "All files pass linting".
The Problems pane still shows the lint error.

I expect the Problems pane to clear the messages from the Run Task when I rerun the task, but it seems to clear the messages only after it parses the results.

[dbaeumer]

@felix9 do you have a repository that I can clone that demos this ? And which tslint extension are you using?

[stewhi]

Has there been any movement on this? I'm encountering the following situation:
Run a watch task with a problem matcher
Introduce a bug
Problem matcher puts an error message on the problems pane
Fix the bug
Problem matcher runs, no errors in the terminal
Problems pane still has the error reported, and the "red squiggle" is still on screen where the bug used to be.
Restarting the watcher clears out the problems pane and red squiggle, but that's less than ideal.

[dbaeumer]

@stewhi this issue is about to clear problems from Task A from Task B. This is not about clearing problems generally. This is tracked here: #66982

Can you provide me with a setup were you see this. In most cases this is caused by not well configured problem matchers.

[mttindustries]

I'm in an agreement with everyone else in this thread. I've opened up several files as I work on multiple projects and it just keeps a log of all the past problems WITH EVERY SINGLE FILE. They don't disappear after closing or fixing them. I have over 1k of problems now because of every-time I forgot a semicolon and it's duplicated 10 fold with all the back-history of each page. Why isn't there a feature to say right click on and mark as solved or clear all? It's the one thing that's letting down this program and is making me contemplate switching back to dreamweaver

[mttindustries]

Currently the only workaround is to use the 'reload' extension
https://github.com/natqe/reload

I tried that, it didn't work for me

[Gruntfuggly]

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

[alexr00]

How would folks who are passionate about this feel about having a command that clears task related problems? I don't want to make a task that does this because we don't have the concept of a universally contributed task. i.e. tasks are contributed by an extension or written by an individual users, not provided by core VS Code. #77214

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[adam-ah]

I can't believe this was closed down again after many previous attempts to convince MS to fix this (eg., #15524, #29169, #66343).
What the heck is going on?

EDIT: Why do you add the "needs more info" on this? After more than a year and 39 comments, what else do we need to clarify?

[alexr00]

I do want to implement this functionality, I just think that it would be better as a command, not a task. Please see the comment I left: #50448 (comment)

[jeiea]

I've set owner of task to something other than external, and it seems to clear same task's problems. I don't know why but satisfied with this for now.

[mttindustries]

I've set owner of task to something other than external, and it seems to clear same task's problems. I don't know why but satisfied with this for now.

How do you do that?

[jeiea]

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "type": "shell",
      "command": "chcp 65001; stack build --fast",
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "problemMatcher": {
        "pattern": {
          "regexp": "^(?:.*?> )?(.*?):(\\d+):(\\d+): (.*?):",
          "file": 1,
          "line": 2,
          "column": 3,
          "severity": 4
        },
        "owner": "haskell" // <- here
      }
    }
  ]
}

Excerpted from here