Explore improving attach problem matcher UX

[alexr00]

The UX that pops the quick pick ever time a task is run is to intrusive.

[alexr00]

The goal is to automatically attach problem matters when possible and let the user know that a problem matcher has been attached.

For detecting whether there is a good problem matcher we can only check for problem matchers that we know might be applicable (ie, only typescript problem matchers in a typescript folder). There are two options for when we look for problems

• We can wait until there have not been new lines in the terminal for m seconds then look at the last n lines for problems.
• We can look for problems in the first n lines after a user hits enter after a command.
  Both options only reason over n terminal lines, so there shouldn't be a large perf impact. This only covers watching problem matchers though. For start stop problem matchers, we can pair the command that was run with the problem matcher we suggest, then when that command is run again we clear the problems from the matcher.

The next questions are how we tell the user that there's a good problem matcher and whether we suggest the matcher of simply attach it. The original idea was to have a button near the terminal selector drop down and when a problem matcher is found, to decorate that button and not automatically attach the matcher. However, a new button is not universally celebrated and if there are split terminals a button won't make it clear which terminal the problem matcher goes to. Because of this it might make more sense to simply attach the problem matcher if we find one. Since this still needs to surfaced in the UI, we could put it in a silent notification.

[alexr00]

Closing the exploration. There will be a new item for what we actually decide to do with this.