GCC -fdiagnostics-color= default

Pádraig Brady P at draigBrady.com
Mon May 27 17:25:07 UTC 2013


On 05/27/2013 06:16 PM, John Reiser wrote:
>> gcc 4.8.0-6.fc19 and later contains a backport of color diagnostics
>> support from gcc trunk.  ...
>> Would users appreciate it being done by default (i.e. make
>> -fdiagnostics-color=auto the default)?
> 
>>> * Any pros/cons?
> 
>> Same thing as pros/cons of colorizing grep or ls output by default.
> 
> Let's make an explicit list.  Here is a start:
> 
> 0. Supposedly the colors provide faster visual communication, increased ease
>    of recognition and understanding, etc.: an "enhancement".
> 
> 1. Background color matters.  The default colors are chosen for a black background.
>    On a white background some of the default colors may be more difficult
>    to process visually.  For example, on a white background I find it
>    much harder to recognize and process the green caret under the terminating
>    right brace of "test.C:1:14: warning: no return statement in function returning non-void [-Wreturn-type]
>      int foo () { }"  in http://gcc.gnu.org/gcc-4.9/changes.html (C family section).

Note 256 colors are supported by default since Fedora 18
and give much more choice for colors that are appropriate
for light or dark backgrounds:
http://fedoraproject.org/wiki/Features/256_Color_Terminals

> 
> 2. Changing the default colors is cumbersome.  Remembering how to turn off
>    the colorization is another straw on the user's back.
> 
> 3. Redirecting stderr to a non-terminal changes the error message.
>    (Configurable; but it is another straw.)
> 
> 4. The bugs in colorized presentation of error messages may be different
>    than in non-colorized presentation.
> 
> 5. No attention has been paid to how colorization affects persons
>    who have color blindness or other visual disabilities.
> 
> 6. Colorization is not being presented as a plugin which uses the API
>    for gcc's warning subsystem.  Is colorization such a plugin?  Why not?
>    How does colorization interact with an existing use of the API for
>    gcc's warning subsystem?
> 



More information about the devel mailing list