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