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