> 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?
--
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
