GCC -fdiagnostics-color= default

[Jakub Jelinek]

On Mon, May 27, 2013 at 10:16:56AM -0700, John Reiser wrote:
> 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".

Yeah, that is the goal.

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

You should test output from the compiler, the web page has the output of the
compiler transformed into HTML colors and bold.  It has been tested with
both black and white backgrounds and uses the grep recommendations for
default color choosing.

> 2. Changing the default colors is cumbersome.  Remembering how to turn off
>    the colorization is another straw on the user's back.

The info page as well as man page documents it, and the format is the same
to GREP_COLORS, just the color names are different.
GCC_COLORS= turns it off, invalid color names are ignored, valid change the
default.  So, right now GCC_COLORS=' ' (invalid color name) or say
GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
e.g. makes it show colors in auto mode by default.

> 3. Redirecting stderr to a non-terminal changes the error message.
>    (Configurable; but it is another straw.)

ls and grep behave the same.

> 4. The bugs in colorized presentation of error messages may be different
>    than in non-colorized presentation.

No, the colors are always just visual highlight of some things, the actual
characters in the diagnostics don't change.

> 5. No attention has been paid to how colorization affects persons
>    who have color blindness or other visual disabilities.

It can be easily disabled, and how is this different from ls/grep default
behavior in Fedora?

> 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?

Why it should be a plugin?  The everything must be plugin mantra is
weird.  It is fully customizable, the diagnostics isn't XML or anything
similar internally, so all a plugin could see in a hook would be the
resulting diagnostics which has info lost.

>    How does colorization interact with an existing use of the API for
>    gcc's warning subsystem?

One can request color start/end manually using %r/%R, plus %<, %> and %qXXX
color automatically.

	Jakub