GCC -fdiagnostics-color= default

John Reiser jreiser at bitwagon.com
Mon May 27 17:16:56 UTC 2013

> 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).

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