Provide Task Runner viewlet

[dbaeumer]

We did a Task 2.0 deep dive today and this issue collects the combined feedback received.

Task Properties

• echo should be true by default so that users get a better idea of the task executed
• we should support flattening the JSON properties as we do with other settings (e.g "terminal.echo": true instead of "terminal": { "echo": true }
• we should better separate task declaration from task customization. Currently both happens in the tasks array property and the differentiating element is the customize property.

Task Picker

The task picker should support a decription / detail message to better explain what the task does. We also discussed whether the task picker should support MRU which would automatically move the most used tasks up to the top without customization. If we provide a task panel (see below) such a MRU list could be useful there as well.

Task Customization

The task customization is currently instance based where the task instance is identified by a task id, which can be quite 'cryptic'. An alternative way would be to identify a task based on a type and a key that is defined by the type and therefore can vary from task runner to task runner. So instead of having something like:

	{
		"customize": "vscode.npm.run build",	
		"taskName": "npm: run build"
	}

a customization would look like this

	{
		"customize": {
			"type": "npm",
			"file": "${workspaceRoot}/package.json",
			"script": "build"
		},
		"problemMatcher": ["$tsc"]
	}

where the structure of the identifying attribute is defined by the extension providing the runner support. In the example above the fact that a npm script is identified by the location of the package.json file and the script name comes from the npm extension. This might look different for task contributed by gulp of TypeScript

Problem Matchers

For task that execute a target of a task runner (e.g. gulp, npm, grunt) VS Code can't decide which problem matchers to attach. Since picking the right problem matcher currently requires editing the tasks.json file we should better support the user with this. We discussed the following ideas:

• always attach all known problem matchers if a task has no problem matchers. This might result in false positives and might require us to support removing problem matchers via a configuration mechanism.
• we could help the user attaching a problem matcher by generically scanning the output for problems and suggest problem matchers that exactly match these. If selected we update the tasks.json file for the user.

Task panel

It was suggested to run tasks in its own panel instead of reusing the terminal panel. They should still be executed using the terminal to get ANSI control character support and other nice terminal features (e.g. Ctrl+C). The panel could offer additional features like:

• a task summary (execution time, exit code, ...)
• the output of a task could be folded (like travis does for example)
• allow for in place customization of a task (for example attach a problem matcher) without the user being forced to edit a tasks.json file.

We also discussed the need of a task viewlet but decided that this will not add any big additional value over the task picker and a separate panel.

Top Level Menu

We were also discussing whether the tasks deserve a top level menu. In general this was consider a good idea. However such a menu should be semantically not technical. So instead of naming it Tools or Tasks it would be better to offer top level menus like Build, Rebuild All, Clean, Run Tests. The downside of such an approach is that such a menu looks out of place if none of these entries trigger any meaningful action in the workspace (e.g. if a simple JS project is open at lease Build, Rebuild All and Clean don't make any sense)

Better Selfhosting

Would be great if we can improve the self hosting coverage of tasks. This is currently hard to do due to the fact how we build. But @dbaeumer will tweak our tasks.json to support more tasks currently run in the terminal (e.g run tests, linting, ...)

[dbaeumer]

@Microsoft/vscode please read. Feedback and corrections welcome.

[Tyriar]

We also discussed the need of a task viewlet but decided that this will not add any big additional value over the task picker and a separate panel.

@Lixire and @aefernandes are currently looking into this I believe.

[Tyriar]

Most of this is In response to:

It was suggested to run tasks in its own panel instead of reusing the terminal panel.

First off, it definitely looks like these sorts of improvements will make tasks more useful and usable. I just wonder if this is the right direction we should be taking:

• We already have output, debug console and terminal which are all very similar.
• We don't deal with overflowed panel actions too well right now, this will make the panel less usable on small monitors and/or high scale/zoom settings. This is what the panel looks like right now on my 13" laptop screen. A new panel may start to squash the panel actions off screen with this window position:
  
• Are tasks generally useful enough to warrant their own panel? Personally I've found little benefit over shell scripts, particularly if you want the project to be portable as tasks are only usable in VS Code.
• Perhaps time invested in tasks would be better spent bringing some of these sorts of features to the terminal, namely Command aware terminals #20676 + Implement Shell Integration xtermjs/xterm.js#576 which could lead to exit code marking, folding of terminal commands and clever problem matching (leveraging settings system for definitions).

Technical details

On the implementation side, this is definitely technically possible. It will put a permanent halt on moving tasks to an extension, I think that effort has fizzled out anyway though.

TerminalInstance is fairly generic right now and it wouldn't require that much tweaking to get working inside another panel. It doesn't have a dependency on TerminalService and communicates with it via events. The main problems you will run into are how terminal keybindings and the terminal context keys interact with the new tasks system:

• terminalTextSelected is fairly easy, this could be changed to be if text is selected in tasks/terminal and that panel is active.

• terminalFocus is a little trickier as making this apply to both task panel focus and terminal panel focus would cause issues with my keybindings, for example:

  { "key": "ctrl+`", "command": "workbench.action.terminal.focus",
                     "when": "!terminalFocus" }

I don't think too much of TerminalService can be reused if we make a tasks panel.

Some alternative ideas:

• We implement terminal tabs and each task gets its own tab Tabs for integrated terminal #10546
• We embed TerminalInstances (ie. xterm.js) within the output panel, disabling stdin by default, then move tasks back to output?
• Refocus effort on tasks on improving the terminal

[dbaeumer]

See #28351 for the echo feedback.

[dbaeumer]

Added support for MRU list:

[alexdima]

@Tyriar I don't think the idea of having a Task panel competes with your mentioned improvements for Terminal. If there is a UX path where Tasks and Terminal can fit in the same panel, that would also be great.

Some reasons why IMHO a Task panel would help:

• It would be nice to see somewhere, in the form of a list, the current running tasks and some sort of history with past ran tasks. From the list, it would be nice to be able to expand output for a task in case there is a problem (sort of like travis).
• Such a list would be especially helpful for managing background tasks
• A panel might help with task discoverability. At this time, there is no obvious UI path to go launch a task or configure a task from a terminal. There is no mention of tasks or the possibility of gathering errors from a task in the UI.

And what would also be very nice:

• It would be nice that typing in the terminal auto-completes with information from the task providers. e.g. typing "gulp c" should complete with the gulp tasks that start with letter c.
• It would be nice that running a command in a terminal can be configured into a task via a one-click. e.g. it would be nice if, when someone runs gcc in the terminal (without a task configured) that we can detect that this would be a prime candidate for a task and we would guide the user into creating a task. I think many folks don't know that a command they run in the terminal can be "lifted" to be even more integrated into VS Code.

[bpasero]

I would still want us to explore the possibility of a panel for tasks, I think UX scalability as reason to not do it is not very fair, we need to solve the panel overflow no matter what in the same way we solved it for the activity bar (being able to show/hide panels, reorder them, see a "..." overflow menu when space is too little).

I do agree though there is some overlap in Debug Console, Integrated Terminal, Output and Tasks, however I am not sure if it would make sense to put them all into one. There is very specific scenarios for each of the panels:

• output: after tasks moved to terminal I would argue output is only ever being used as a way to see diagnostics (I wonder if we should make output less prominent)
• debug console: has rich functionality when debugging, but otherwise is quite useless (maybe we should only show it when you are in a debug session?)
• terminal: this is where I execute shell commands. nothing in here is related to VS Code, it is just convenient to not have to leave VS Code to use it
• tasks: this is VS Code specific: I execute potentially multiple long running tasks, each with output and progress and possible error conditions (markers)

Here is a mockup for the Tasks panel:

We can provide an explicit configure action per task which would guide users to configure problem matchers.
We can make all tasks discoverable from here by having a dropdown to show all tasks that can be executed.

/cc @stevencl

[dbaeumer]

@bpasero thanks for the nice mockup.

[jrieken]

Any new ideas wrt task customisation and referencing (contributed) tasks by an id or something else? I think from the API POV that is a thing to tackle.

[chrmarti]

Not being an active task user myself, I wonder if the suggested Tasks panel could also show processes run from the Terminal. That could then open a path to offer problem matchers for tools run in the Terminal.