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

Emit color job progress and job failure messages by default #1455

Closed
wants to merge 2 commits into from

Conversation

mqudsi
Copy link
Contributor

@mqudsi mqudsi commented Jul 31, 2018

Set the default NINJA_STATUS and the "FAILED" text on job failure to
use ANSI color code escapes if running under a smart terminal.

Requires #1454 to be merged first.

mqudsi added 2 commits July 30, 2018 18:50
Adds support for ANSI escape sequences used for colorization to the job
status indicator, and updates `ElideMiddle()` to account for the
non-obvious change in text width.

As an example, the following will now emit the job status in green:

   env NINJA_STATUS="\\033[32m[%f/%t] \\033[0m" ninja;

Invalid color escape codes are treated as plain text (as before). ANSI
escape sequences apart from `\033...m` are not supported.

Closes ninja-build#713. Closes ninja-build#912.
Set the default `NINJA_STATUS` and the "FAILED" text on job failure to
use ANSI color code escapes if running under a smart terminal.

Requires ninja-build#1454 to be merged first.
@nico
Copy link
Collaborator

nico commented Nov 15, 2018

This is inherently subjective. We think the current default is a good default; it looks like you'll be able to set the env var to include color codes to get this locally soon.

@nico nico closed this Nov 15, 2018
@mqudsi
Copy link
Contributor Author

mqudsi commented Nov 15, 2018

I don’t think it’s a subjective request at all. Ninja output for complicated jobs is a wall of text. It’s virtually impossible to find the end of one job and the start of another when scrolling back in the buffer.

(And yes this is contingent on support for ANSI color escapes from either of the two PRs to add that.)

The reason why the current default doesn’t have colors is because it was literally impossible before those PRa were merged, whether via a local environment variable or hard-coded in the code, due to the incorrect calculation of character widths. It is unfair to say “we probably got this right when there literally was no choice at the time of doing it differently.

@jhasse
Copy link
Collaborator

jhasse commented Nov 16, 2018

Eliding with ANSI escapes is slower (if done correctly, see WIP about this in #1494), that's why we're reluctant to change the default. You also can't use smart_terminal as that is still true for Windows <10, which doesn't support ANSI color escapes.

Coloring the "FAILED:" message does sound like a good idea to me though.

@mqudsi
Copy link
Contributor Author

mqudsi commented Nov 17, 2018

@jhasse Thank you for providing legitimate reasons for not taking this. Do you want me to open a separate PR for the red failure messages or rebase this one for you guys to reopen? Also, what do you recommend in lieu of smart_terminal?

@jhasse
Copy link
Collaborator

jhasse commented Dec 4, 2018

Do you want me to open a separate PR for the red failure messages or rebase this one for you guys to reopen?

Open a new one.

Also, what do you recommend in lieu of smart_terminal?

There's supports_color_ now, which needs to be set to false on Windows if SetConsoleMode(console_, mode | ENABLE_VIRTUAL_TERMINAL_PROCESSING); didn't work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants