Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ANSI colours in output window #12

Open
apgrucza opened this issue Mar 27, 2023 · 6 comments
Open

Support ANSI colours in output window #12

apgrucza opened this issue Mar 27, 2023 · 6 comments
Labels
area: output Changes related to the vscode output window and terminal type: enhancement A change to an existing feature or functionality.

Comments

@apgrucza
Copy link

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
Copy link
Member

pd93 commented Mar 27, 2023

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:

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
Copy link
Author

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
Copy link

mhmdio commented Mar 27, 2023

+1 here, found it nice to have
cleanshot-20230327 -181211

@pd93
Copy link
Member

pd93 commented Mar 28, 2023

@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
Copy link
Author

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
Copy link
Member

pd93 commented May 3, 2023

@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.

@pd93 pd93 added type: enhancement A change to an existing feature or functionality. area: output Changes related to the vscode output window and terminal labels Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: output Changes related to the vscode output window and terminal type: enhancement A change to an existing feature or functionality.
Projects
None yet
Development

No branches or pull requests

3 participants