Support ANSI colours in output window

[apgrucza]

Text in the output window should appear coloured if the task outputs ANSI escape codes that set the text colour.

For example:

tasks:
  colour:
    cmds:
      - echo -e "Add {{.RED}}new{{.NC}} feature"
    vars:
      RED: \033[1;31m
      NC: \033[0m

When this task is run via the extension, the text in the output window should appear as:

Add new feature

instead of:

Add �[1;31mnew�[0m feature

[pd93]

I definitely agree that the lack of colours in the output window isn't great. However, as it stands, the VSCode output windows doesn't support custom coloured output unfortunately :(

See related issues:

• task runner output doesnt show color for gulp taks with --color switch arg microsoft/vscode#243
• ANSI colors in OutputChannel microsoft/vscode#571

The only way to get coloured output there is to specify a language ID which will add syntax highlighting to any matching grammar. Theoretically I could add something that would add colour to Task names etc, but this would not solve your issue.

An alternative might be to use the terminal API for task output instead. This would support full ANSI colour output, but I'm not fully sure how this would work yet. Keeping this open until I have some time to do more research.

[apgrucza]

Thanks for the explanation. This extension for Task sends task output to a terminal window, which explains why it's able to support ANSI colour.

[mhmdio]

+1 here, found it nice to have

[pd93]

@apgrucza @mhmdio I've been trying a few different things out and I'd be grateful for your thoughts on how you would expect the extension to work if it used the integrated terminal.

• Would you want tasks to run in a normal terminal that you can use for other commands or should it have a dedicated terminal just for Task?
  • If the former, what happens if you already have a terminal open and more importantly, what if that terminal has a long running process (such as a server or file watcher).
  • If the latter, should each task clear the previous output, or should the output be appended.
  • Should the terminal be read-only or writable?
• Should this replace the output window or be a toggle in the settings?
  • If we keep the output window, should we strip ANSI codes?
  • Which should be the default?

I have my own opinions on some of these, but I'd like to see if they align with your expectations. Thanks :)

[apgrucza]

I would want tasks to run in a normal terminal that you can use for other commands. I have an authentication tool that obtains access tokens and puts them into environment variables (which most of my tasks rely upon). I need to be able to run this tool first, and then run the tasks in the same environment.

If I already have a terminal open, I'd want to be able to run tasks inside that terminal (so they can pick up any environment variables that are set in that shell). But I imagine there could be cases where people don't want their terminal interfered with and would prefer it to run in a dedicated Task terminal. So, we should probably have two commands: "Run Task" and "Run Task in Active Terminal". The Task window could have buttons for both. If we give users this choice, the dedicated Task terminal can be read-only.

If there were a single dedicated terminal just for Task, then I think the question about long-running processes is still relevant if the user tries to run a task before the previous one has finished. Is it possible to detect if the terminal is busy? What are the options here? If the terminal is busy, we could:

1. Show an error
2. Run the task when the terminal becomes ready
3. Run the task in a new terminal
4. Show a message box that lets the user choose between options 2 and 3 or Cancel

Option 2 could become quite powerful if it allowed the user to queue up a number of tasks to be run one after another (aborting as soon as a task fails). I'm leaning towards this option, but if it's difficult to implement or outside the scope of this issue, option 1 should suffice. I do not like option 3 as the environment of the new terminal may differ from that of the active terminal.

In a dedicated Task terminal, I think the default behaviour should be to not clear the previous output. Users always have the option to clear the terminal manually with the Clear Terminal command in the toolbar before they run a task. It would however be useful to have a setting to automatically clear the terminal, as people's preferences will vary.

I don't see much value in retaining the existing output window. The only advantage I can see is that tasks can be run concurrently, but the intermingling of task output into the window makes this less useful (especially when combined with the current auto-clear behaviour). Besides that, it's just more code to maintain. If it's removed, then the "Task (Debug)" window could be renamed to just "Task".

To support running multiple tasks concurrently, we could consider these options:

• Make "Run Task" always open a new terminal, with a "press any key to close terminal" prompt at the end (like this extension does)
• Add a third command called "Run Task in New Terminal"

But I feel it might be better to keep things simple and wait to see if there is demand for this. Users can always open multiple terminals and use "Run Task in Active Terminal" to run tasks concurrently.

[pd93]

@apgrucza Thanks for your insight. It's really useful to get other people perspective on this as I suspect that these changes will be somewhat subjective. I've opened #43 to address the most basic possible use case (running in an existing terminal).

I'm going to leave this open for now so that I can investigate some of the other options discussed here. As you eluded to, option 2 sounds pretty good, but the VS Code API is limited in what it can do with a terminal, so more thought is required. Hopefully, the changes in #43 will help you with your use case in the mean time.