support terminal color output

[placrosse]

When running cargo from terminal, output is colorized. Apparently, flags are required to cargo to force color output always, as it is not output to non-terminals.

Could an option, similar to that for --verbose, be added so cargo output is forced to emit the colors by passing cargo the necessary parameters?

[alygin]

Changes from the PR work fine on Linux and Mac, but Windows is not so easy.

Based on the Rust source code, I finally made it work on Windows via msys. But I'm not sure if this is a reliable solution, and moreover, the console in atom-build displays the output incorrectly.

Here's what I expect (taken from the standard terminal on Windows):

Here's what I got on Windows with msys (taken from atom-build):

Have someone encountered such a problem before? Any suggestions on how to solve it? @noseglid, maybe there were similar problems in other builder packages and there's a known solution? @jhasse, you made some changes in that piece of Rust code, maybe you know how to force colors on Windows in more reliable way?

[noseglid]

It looks like the reset character \003[0m is not respected for some reason. So the color just keeps on going with the current color until there is a new color shown. Could you hexdump the output just to see what's in there?

It could be an issue with term.js that atom-build is using. It is in charge of converting terminal output to html. It's actually a slightly modified version: https://github.com/jeremyramin/term.js which is the same as used in the terminal-plus package.

[alygin]

Here's the output of the same build with all ANSI codes: output.txt.

[noseglid]

Something definitely seems wrong with the output. This is what I'm getting i iterm2 on OSX.

The ansi reset markers does indeed seem to be missing. Here's the hexdump:

00000000  73 72 63 2f 6d 61 69 6e  2e 72 73 3a 31 30 3a 39  |src/main.rs:10:9|
00000010  3a 20 31 30 3a 31 34 20  1b 5b 31 6d 1b 5b 33 31  |: 10:14 .[1m.[31|
00000020  6d 65 72 72 6f 72 3a 20  1b 5b 31 6d 6d 69 73 6d  |merror: .[1mmism|
00000030  61 74 63 68 65 64 20 74  79 70 65 73 1b 5b 33 35  |atched types.[35|
00000040  6d 20 5b 45 30 33 30 38  5d 0a 73 72 63 2f 6d 61  |m [E0308].src/ma|
00000050  69 6e 2e 72 73 3a 31 30  20 20 20 20 20 62 20 3d  |in.rs:10     b =|
00000060  20 34 33 75 33 32 3b 0a  20 20 20 20 20 20 20 20  | 43u32;.        |
00000070  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 1b  |               .|
00000080  5b 31 6d 1b 5b 33 31 6d  5e 7e 7e 7e 7e 0a 73 72  |[1m.[31m^~~~~.sr|
00000090  63 2f 6d 61 69 6e 2e 72  73 3a 31 30 3a 39 3a 20  |c/main.rs:10:9: |
000000a0  31 30 3a 31 34 20 1b 5b  31 6d 1b 5b 33 36 6d 68  |10:14 .[1m.[36mh|
000000b0  65 6c 70 3a 20 1b 5b 31  6d 72 75 6e 20 60 72 75  |elp: .[1mrun `ru|
000000c0  73 74 63 20 2d 2d 65 78  70 6c 61 69 6e 20 45 30  |stc --explain E0|
000000d0  33 30 38 60 20 74 6f 20  73 65 65 20 61 20 64 65  |308` to see a de|
000000e0  74 61 69 6c 65 64 20 65  78 70 6c 61 6e 61 74 69  |tailed explanati|
000000f0  6f 6e 0a 73 72 63 2f 6d  61 69 6e 2e 72 73 3a 31  |on.src/main.rs:1|
00000100  30 3a 39 3a 20 31 30 3a  31 34 20 1b 5b 31 6d 1b  |0:9: 10:14 .[1m.|
00000110  5b 33 32 6d 6e 6f 74 65  3a 20 1b 5b 31 6d 65 78  |[32mnote: .[1mex|
00000120  70 65 63 74 65 64 20 74  79 70 65 20 60 69 33 32  |pected type `i32|
00000130  60 0a 73 72 63 2f 6d 61  69 6e 2e 72 73 3a 31 30  |`.src/main.rs:10|
00000140  3a 39 3a 20 31 30 3a 31  34 20 1b 5b 31 6d 1b 5b  |:9: 10:14 .[1m.[|
00000150  33 32 6d 6e 6f 74 65 3a  20 1b 5b 31 6d 20 20 20  |32mnote: .[1m   |
00000160  66 6f 75 6e 64 20 74 79  70 65 20 60 75 33 32 60  |found type `u32`|
00000170  0a 1b 5b 31 6d 1b 5b 33  31 6d 65 72 72 6f 72 3a  |..[1m.[31merror:|
00000180  20 1b 5b 31 6d 61 62 6f  72 74 69 6e 67 20 64 75  | .[1maborting du|
00000190  65 20 74 6f 20 70 72 65  76 69 6f 75 73 20 65 72  |e to previous er|
000001a0  72 6f 72 0a                                       |ror.|

Look at the first error:. According to your reference from "standard terminal" on windows the colon should not be colored ,but there are no special characters between error and :.

Could it be that the program (rustc) looks at some further environment variables/tty to determine how to operate?

[jhasse]

Rust uses terminfo to determine which color codes to support. So the ANSI codes it outputs could be ANYTHING.

The only reliable way to make this work in atom would be, when the rust developers would merge this PR I wrote: rust-lang/rust#27867
It makes it possible to enable standard ANSI colors independent of terminfo / the operation system.

[alygin]

@noseglid, yes, the output looks invalid and it seems that we cannot use msys terminal to properly color rustc's output in build-atom.

@jhasse, you PR would make forcing color output easier, but since it leaves the method msys_terminfo() intact (except renaming it), it would keep all the problems with incorrect formatting.

But I still think there must be another way to make rustc produce output that we could rely on. It obviously works on Windows in some mode, I just can't find the branch of code that switches it to that mode. It might also occur that rustc uses Win API calls (instead of emitting ANSI codes) to format the output on Windows. In this case, I think, nothing can be done on the atom-build side to make it work. But I hope it works another way and there's some switch that could be leveraged.

[jhasse]

msys_terminfo should send the reset code, if not, thats a bug.

Yes, rustc uses the Windows console API when it doesn't detect that it's running inside a MSYS terminal.