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