Vscode: Automatically show the Problems panel when a task yields problems

[akbyrd]

Issue Type

Feature Request

Description

When problems are matched while running a task, I'd like the Problems panel to automatically appear. This is especially useful if I have presentation.reveal set to never.

VS Code Info

VS Code version: Code 1.20.1 (f88bbf9137d24d36d968ea6b2911786bfe103002, 2018-02-13T15:34:36.336Z)
OS version: Windows_NT x64 10.0.16299

[vscodebot[bot]]

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

• Suggestion: Automatically show the Problems panel if problems exist (and hide similarly) (#10400)
  

[akbyrd]

The above linked request is related, but more involved than this one. The linked request is looking to show/hide problems in real time while editing code. I'm simply looking for an option to "show problems when running a task".

Perhaps these changes to the presentation section:

reveal: always, never, auto (previously silent)
viewlet: problems, terminal

[dbaeumer]

The presentation.reveal is for the terminal. We would need another property to indicate the reveal of the problem panel.

[akbyrd]

Yes. The above proposed change to reveal would repurpose it to apply to whichever viewlet (panel? not clear on the difference) is currently enabled. The reasoning being that Problems and Terminal are mutually exclusive as currently implemented so having separate revealTerminal and revealProblems settings might be confusing.

Not necessarily the best solution, just an idea.

[DragWx]

I was looking for a feature like this too; the terminal is fine, but the problems panel is filtered and sorted.

An edge case would be if your build task can produce errors that your problem matchers won't match. For example, in C/C++, an unresolved extern symbol will generate a linker error, and the linker's error output is formatted differently from the compiler's (referring to gcc.exe and ld.exe here), and the current C/C++ tools do not contain a matcher for linker errors, so this would result in an unsuccessful build, but with the build error not being sent to the problems panel.

I'm not sure what a good solution to this would be (or if there even needs to be one), but it wouldn't be a deal breaker to still need to occasionally check the terminal output.

[nox]

@dbaeumer Is this something that could be easily done with some guidance?

[alexr00]

@nox yes, take a look at e3f803d92 where I recently made a change to the presentation options. Instead of editing vscode.d.ts as that change does, you can modify vscode.proposed.d.ts and then I'll take the change through our API review process. For showing the problems pane when a problem occurs, check out https://github.com/Microsoft/vscode/blob/8a6778cecc020fa438446ade9a9030b399e988ff/src/vs/workbench/parts/tasks/common/problemCollectors.ts#L36 Specifically the deliverMarkers* methods could be a good place to signal that it's time to open the problems pane. You could add a new event to AbstractProblemCollector, subscribe to the event in places that use a problem collector, and in the callback for the event open the problems pane.

I think having a new presentation option called revealProblems makes sense here. It could have options onProblemFound and never. We could also have an always value, but that could conflict with showing the terminal if reveal is set to always,

[nox]

Wouldn't it make more sense to make a new setting to specify which panel to reveal, as suggested by @akbyrd earlier?

[alexr00]

I think having revealProblems will provide more flexibility. Showing the terminal when a task starts could always be useful if you care about what our task is outputting. However, showing the problems pane when your task starts will probably be useful less often. If we have separate reveals for terminal and problems then you get to say "reveal":"always" and "revealProblems":"onProblemFound". We also shouldn't break anyone's existing task configurations by changing the possible values of reveal.

[nox]

I don't understand why the problems pane would be less useful. For example in the context of Rust, the output of the compiler itself in such a tiny pane is absolutely unreadable. Furthermore, it seems weird to me to have two "reveal" settings when the two panes can never be shown both (right?).

Let's say we do "reveal" and "revealProblems", do you mean that the terminal pane should be showed first, and the moment rustc emits an error it should then show the problems pane? That sounds like it would have the same UX as a FOUC on the Web.

[nox]

We also shouldn't break anyone's existing task configurations by changing the possible values of reveal.

Note that this wouldn't break anything, given the new "which pane to show by default" setting would default to the terminal one, of course.

[alexr00]

Ok, I'm alright with viewlet having possible values of terminal and problems. reveal would need to keep it's existing possible values of always, never, and silent.

[akbyrd]

@alexr00 How do you feel about adding a new value while still keeping the existing ones? Will this keep the backwards compatibility you're after?

My reasoning is that none of the existing values match the new behavior. always and never are obviously out and silent is documented as "Only reveals the terminal if no problem matcher is associated with the task and an error occurs executing it". That doesn't describe what we're after here at all, and trying to reuse it for this different behavior would be extremely confusing, in my opinion.

If reveal is re-used for both viewlets, I think adding a new option such as auto or onProblemFound is the best choice.

That said, I'm also completely ok with separate revealTerminal and revealProblems options that are just mutually exclusive (assuming the UI does the right thing and doesn't flicker between them or anything). This has a couple of benefits 1) the value for each can differ and have more descriptive help text, and 2) if it ever becomes possible to see both viewlets at the same time the separate options will continue working nicely, while the combined option would become quite awkward.

In fact, I've just convinced myself separate options is a better bet.

[alexr00]

@akbyrd I would still prefer to have two separate options, one that controls reveal of the terminal and one that controls reveal of the problems pane 😊 so I'm mostly on board with your suggestion. In particular, I think haveing separate options does future-proof us better.

One thing I don't want to do is abandon the current reveal value. I do want to keep using that for the terminal reveal if we go with the separate value approach. If we abandon it then it's deprecated code that still needs to be maintained.

A new revealProblems option should have similar values, such as always, never, and onProblemFound.

[nox]

I didn't realise at first that the values of reveal wouldn't fit for the problems pane, so I agree now that revealProblems is probably the way to go.

[drewlustro]

I would love this

[sebastianwitthus]

@alexr00 Please check out my fork with a working commit on branch 44146-automatically-show-problems-pane regarding this issue.
There's a new option, revealProblem, with values Always, onProblemFound, Never; defaulting to Never.

1. There's a slight problem: What to show when both reveal and revealProblem are set to always? One option has to take precedence.
2. What speaks against a reveal: onProblemFound option to show the terminal when problems are found? RevealKind is an enum anyway, so just add it as value option 4? (Currently: Always = 1, Silent = 2, Never = 3)
3. If reveal: onProblemFound is implemented, problem 1. arises for each problem.

[akbyrd]

Thanks for taking a look at this!

1. It's somewhat arbitrary, but I'd lean towards problems taking precedence. That would allow support for a scenario where the terminal is always shown when there are no problems and problems are shown when they exist. That seems like a useful case I imagine myself using.

   The reverse situation doesn't appear to be useful. If terminal takes precedence you simply never see problems and the option becomes useless.

2. I can't think of a strong reason not to. Some people prefer looking at output directly rather than the parsed output in problems (several people on my current team). For those people it's a useful option.

3. Same as 1.

[rickvanprim]

Always showing Terminal, and then conditionally showing Problems if any are found after the task completes is the same behavior as Visual Studio (and what I'd personally like to see in VS Code).

[alexr00]

@sebastianwitthus thanks for working on this one! Can you make a pull request to Microsoft/vscode?
For your questions:

1. I would also give "revealProblem" precedence. We should include that in the description of both reveal and revealProblem.
2. Supporting onProblem for reveal sounds good to me.
3. Agree with @akbyrd, same as 1.

For @rickvanprim comment, I would expect having revealProblem take precedence and setting "reveal":"always", "revealProblem":"onProblem" to give that behavior.

One small change:onProblem instead of onProblemFound. It is more concise and still very clear. "Found" implies to me that we are searching for problems, when instead we are waiting for problems.

[sebastianwitthus]

Thanks for the feedback, I'll work on it 27/28 March

Edit:

Pull request created

[alexr00]

To verify:

1. Try setting the following presentation properties on a task:

"presentation": {
  "reveal": "always",
  "revealProblem": "onProblem"
}

1. Try various combinations of reveal(for the terminal) and revealProblem(for the problems panel).
2. Verify that revealProblem takes precedence over reveal and that other combinations make sense.

[isidorn]

@alexr00 this works nice. However here's some feedback and you can think if you want to create seperate issues for it
revealProblems sounds like a better name for me, since the name of the panel is Problems not Problem.
Description of the reveal attibute should be changed to not say that it reveals the panel, but that it reveals the terminal. Especially since the description of the attributes talks about the termianl.
I find it funky that these two attributes sort of conflict with each other, but due to historic reasons I understand why we went with this.