Extend tasks API to allow programmatic problem matching

The new tasks APIs (fetchTask(), executeTask(), task events…) makes it more convenient to use vscode’s own task system to spawn child process (as opposed to using something like child_process, for example). Still, AFAICT, there are two bits missing in the API:

1. A method to get the underlying Terminal instance of a running task (maybe through TaskExecution?);

2. Events that would be fired whenever something is written in the process’ stdout/stderr (that would probably go in the Terminal instance itself)

This would be very useful to implement UI feedback (i.e progess notifications) while using vscode’s task system. Right now, the only way I see to do that is to spawn my own proces, create an output channel and handle problem matching myself…

Does that make sense?

[dbaeumer]

Actually that tasks are executed in a terminal is still an implementation details (there are even legacy tasks which don’t even run in a terminal). In addition there are requests to be able to run a task in a external terminal. As soon as we would add such a API we are basically hooked into this. This is why I feel very reluctant of adding this in the API.

Adding access to stdout / stderr is a request we do have and I fully support having in the API.

[g-arjones]

@Tyriar I see… It seems that this really isin’t suited to get stdout from a task started in an integrated terminal… 😦

I will open the issue for the processId bug, I guess I can work around the other issues if I have a reliable way of getting the PID of the process currently running in the terminal