Re: [PATCH][mingw] Enable colorized diagnostics

[Liu Hao <lh_mouse at 126 dot com>]

On 2017/10/10 6:25, Manuel López-Ibáñez wrote:
> For what is worth, the color output of GCC comes originally from grep, 
> and grep does have code for colorizing in Windows: 
> http://git.savannah.gnu.org/cgit/grep.git/tree/lib
>
> and there are significant differences with this patch. For once,
>
>    /* $TERM is not normally defined on DOS/Windows, so don't require
>       it for highlighting.  But some programs, like Emacs, do define
>       it when running Grep as a subprocess, so make sure they don't
>       set TERM=dumb.  */
>    char const *t = getenv ("TERM");
>    return ! (t && strcmp (t, "dumb") == 0);
>
> and they don't need a custom fputs() because their strategy is slightly 
> different: They only override colorize_start (print_start_colorize) and 
> colorize_stop (print_end_colorize) and convert ANSI sequences to W32 
> sequences on the fly. Thus, we wouldn't need to touch pretty-printer.c
Since on *nix it is not when `colorize_start()` is called that the 
terminal color is changed (it is when those ANSI escape codes are 
delivered to the other peer which will translate them), and the string 
passed to `fputs()` is free to deliver multiple escape codes, it is not 
an option unless we output integral diagnostic messages using multiple 
fputs()` calls.

For example,
```
test.c:3:9: warning: 'a' is used uninitialized in this function 
[-Wuninitialized]
```
The words 'warning' and '-Wuninitialized' should be magenta, so there 
are four ANSI escape codes (two to set the color and another two to 
restore the color), and this line of text must be output using five 
individual calls to the `fputs()` function (one for each segment with 
the consistent color), which is not the case (this whole line of text is 
delivered using a single call), so all five segments have to be all in 
magenta or no color at all. This is not a solution.

> and all changes will be restricted to diagnostic-color.c (which could be 
> split into -posix.c and -w32.c like grep does and be moved into 
> host-specific config/ subdir).
>
> Even if the host-specific part is not done, I honestly think it is a 
> good idea to match grep's code as much as possible since we may want to 
> merge bugfixes between the two and eventually this code may end up in 
> gnulib. Moreover, if somebody else implemented color output for another 
> OS in grep, it would be very easy to transplant it to GCC (or viceversa) 
> if the API remains close.
>
> Cheers,
>
>      Manuel.


--
Best regards,
LH_Mouse