This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updated GCC vs Clang diagnostics


On 13 April 2012 08:03, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote:
>> Lawrence Crowl <crowl@google.com> writes:
>>
>> > On 4/12/12, Manuel López-Ibáñez <lopezibanez@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).

This is exactly what I would like to implement, if I am allowed.

But I don't want to turn the diagnostics machinery upside down and
implement a "diagnostics internal language" (which I already did in
XML http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c10, and it sits
there useless), just to achieve this.

I just want to have a little file called colors.c which abstracts the
color implementation including the handling of GCC_COLORS. And add the
least amount of code needed to diagnostics.c to check whether the
prefix (warning|error|note) should be colored, the caret should be
colored, and perhaps the message itself should be colored (or not,
once you see the prefix, it is easy to identify the start of
messages). That is all that I am proposing.

Now, if I can get enough support for this to hope that with a nice
implementation it will get accepted, then I will try to get it done.
Otherwise, I will just forget about it and enjoy the sun.
Cheers,

Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]