On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote:
> Lawrence Crowl <cr...@google.com> writes:
>
> > On 4/12/12, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote:
> >> So given your ideal implementation, if the user-visible result
> >> was exactly like the one in Clang, will you be happy with any of
> >> the three things: ranges, color and fix-it hints?
> >
> > There are many issues with color. Does your reader have any
> > color deficiencies? Does your software address them? Does the
> > system software render colors well? Is color contrast sufficient?
> > Is greyscale contrast sufficient? Color is low on my list of
> > desirables.
>
> It would be terrible if an error message could not be understood without
> color. But nobody is suggesting that.
>
> The question at hand is whether color can be used to enhance an error
> message that can be understood without color. For example, whether
> color can be added to current error messages without any other changes.
>
> I personally think it would be an excellent idea. Even clang's C++
> error messages can be long. A simple use of color is an excellent way
> to draw the eye to the more important parts of the message. If the
> color is not available, then it doesn't help, but the error message can
> be understood without it.
Yeah, I second this. As Manuel said, we should have an option to select
never/auto/always coloring, colors must be just visual enhancements of the
diagnostics that even when colors are disabled gives all the info that
is needed (highlight error/warning/note diagnostic kind keywords, keywords
in the source, perhaps types, whatever), we should limit to a very small
set of colors, because not so many colors are actually very readable and
perhaps make the color sets configurable somehow (things might be different
if people use normally black characters on white background or white
characters on black background, grep has GREP_COLORS env var here, ls
LS_COLORS).
Jakub
