Support color in NINJA_STATUS

[mathstuf]

It would be nice if ninja understood color natively. Currently, I have a wrapper script which tests stdout for being a terminal and changes NINJA_STATUS accordingly. The problem is that ninja doesn't know that the color escape sequences are really zero-width when printed on the terminal and causes elision to happen at improper places.

[evmar]

I think bash handles this by special markers that delimit regions that have
no width. Would that work for you?

brevity due to phone

[mathstuf]

On Tue, Jan 28, 2014 at 08:54:00 -0800, Evan Martin wrote:

I think bash handles this by special markers that delimit regions that have
no width. Would that work for you?

Looking at zsh, it uses %0{$zero_width%} to denote such sections. I
don't see anything in the bash man page, but I'd be fine with that as
well.

[mathstuf]

It looks like bash uses '[' and ']' to delimit zero-width portions. Do you have a preference? Maybe something else?

[mqudsi]

Why not just hard-code an ignore for ansi escape codes (or at least ansi escape color codes) when counting the characters as #912 is trying to do?

This seems to be going about it the hard way, adding complexity both to the code and to the language. Current situation: no ansi codes are supported in JOB_STATUS. If we go with a hard-coded patch for ansi color codes, the situation becomes no ansi codes aside from ansi color codes are supported in JOB_STATUS but with zero additional cost or complexity (aside from a change to the status length counter function).

This could have been a twenty minute patch, but now it's turned into a five-year ordeal due to difficult decisions finding the perfect syntax.

[jhasse]

Why not just hard-code an ignore for ansi escape codes (or at least ansi escape color codes) when counting the characters as #912 is trying to do?

Yes, that sounds like the best idea. Ideally that counting should only be done once (when parsing NINJA_STATUS) and not in ElideMiddle.

Current situation: no ansi codes are supported in JOB_STATUS.

It's supported:

env $'NINJA_STATUS=\x1b[32m[%f/%t] \x1b[0m' ninja

The problem is EllideMiddle.

[mathstuf]

To do the count once, a map of console width to string length would be necessary. But it is possible to elide it as long as the description never contains ANSI escape sequences. If it does support that, you need to figure out ConsoleWidth every call.

[torarnv]

I was happy to see that NINJA_STATUS supports ANSI color codes, but surprised to see that adding those made the actual build message elided/truncated earlier than the width of the terminal. +1 on fixing this by just ignoring ANSI escape sequences when computing the eliding.

[mathstuf]

See #1584.

[torarnv]

@mathstuf As far as I can tell #1584 is about stripping color codes for non-color capable terminals/output. The problem reported above is that ninja's eliding logic doesn't take escape codes into account. It should, when deciding how to elide the output, regardless of the output terminal's capabilities.

[mathstuf]

Sorry, I meant #1494.