build: suggestion to make parallel build output more colorblind friendly

[emidoots]

Zig Version

master

Steps to Reproduce and Observed Behavior

Feel free to disregard/close this issue if you like, I don't mind. Just figured I'd pass along my thoughts.

Right now the color-distinguished output for the parallel builds isn't great for me personally, e.g. someone sent me this screenshot and I wasn't able to tell success, passed, and transitive failure are actually green/yellow/red(?):

I have particularly bad colorblindness compared to most others; and no doubt this would look better with the contrast in my terminal compared to theirs. But there is a joke "I can't drive, my hands don't work well" -> "What if we made the steering wheel larger?" about how, frankly, color blind modes suck. Sometimes they help me marginally but for a lot of folks distinguishing things with colors just is not the way their brain is wired.

For me that screenshot above is barely more legible than this binary black/white version:

Expected Behavior

What would really help me a lot is if we could include any symbology. Some examples:

• Include Unicode characters like ✓ ❌ for success/fail
• Or emphasize words with brackets/braces, e.g. [[success]] instead of success like run ecs-tests 5 passed [[success]] 5ms MaxRSS:8M
• Or any other non-color distinguishing that can be done :)

Like I said feel free to disregard/close, I realize this could make the output more cluttered. Might help in CI outputs too, though?

[andrewrk]

I think the most important thing is for the failures to stand out; success and transitive failures are uninteresting. Ideally your eyes should jump to

zig test dusk-tests Debug native failure

when looking at the build summary, since that is the most important line (apart from the "build summary" line itself, and the actual error messages above that).

Question for you: does the faded out text really not look faded out to you? Specifically, "transitive failure"

[mlugg]

(Presumably it looks faded out but that's indistinguishable from a lot of colors?)

[emidoots]

^ Yes, honestly just reading quickly I see three colors: bright text, dark text, and the background. The faded-out text does look faded-out.

The primary problem is that transitive failure and failure look identical to all the dark text metadata like 10s MaxRSS:30M etc.

[andrewrk]

I'm thinking maybe we unconditionally replace └─ with └❌ .

This has the downside of introducing a dependency on Unicode (the box drawing stuff can be done with DEC terminal codes), but perhaps it is worth it regardless. Related: #14411

[InKryption]

What if using └❌ is made the default behavior, and an option is added to fallback to DEC if necessary?

[mitchellh]

I'm extremely sympathetic to your needs here, but a potentially naive question: Zig is already using palette colors for this (i.e. "red" vs. explicitly specified RGB). In a situation like this, is the expectation that a program output alternate colors or that the person with difficulty seeing the colors alter their terminal emulator's palette? I'm not trying to blame you Stephen, I'm just trying to educate myself.

Second question and a real suggestion: Are there alternate colors either in the 256 color spectrum or RGB spectrum that would work here? The 256-color spectrum is well supported by all terminal emulators:

Additionally, pretty much every terminal used today supports 24-bit (RGB) as well: https://en.wikipedia.org/wiki/ANSI_escape_code (grep "24-bit"). It looks like this:

ESC[38;2;⟨r⟩;⟨g⟩;⟨b⟩

I feel like we can maybe just get colors that are friendly to color vision challenges rather than introduce Unicode dependencies.

[mlugg]

Stephen isn't necessarily suggesting using alternate colors:

But there is a joke "I can't drive, my hands don't work well" -> "What if we made the steering wheel larger?" about how, frankly, color blind modes suck. Sometimes they help me marginally but for a lot of folks distinguishing things with colors just is not the way their brain is wired.

Instead, the idea seems to be that color-coding often just doesn't work for color-blind peeps, even if they're recognisable colors, and that having symbolic characters is instead more useful for them, hence the discussion of using Unicode symbols like ❌ to differentiate failures.

[mitchellh]

Ah, good call out. Thanks and apologies for not being aware, I'm quiet inexperienced in satisfying these needs in the terminal. In that case, if we're worried about Unicode, you can use DEC Technical Character Set (TCS) multiplication symbol: https://en.wikipedia.org/wiki/Multiplication_sign Switching to the TCS is the same as graphical set, but the special codepage symbol is ASCII <. And the multiplication sign is 0xCB.

We can also just use Unicode, just want to share all possible info I know of.

[rohlem]

Since we all seem to agree that the "ok" entries are not worth looking at (unless you're new to a project, or just added a new test you're now looking for),
would it maybe be easiest to just add a flag --hide-success? (And if so, should that maybe become the default?)
That would reduce the ~20 lines in the example to the relevant 4, without requiring any new design/workaround ideas.
EDIT: Only now found out about --summary=failures - basically I think I'd advocate for this to be the default.

(An alternative option would be to allow hiding child nodes of "all success" branches - that way a failure branch sticks out because of its children.
I don't prefer that variant personally, but it might be better for some work flows? idk)