public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Lawrence Crowl <crowl@google.com>
To: Ian Lance Taylor <iant@google.com>
Cc: "Manuel López-Ibáñez" <lopezibanez@gmail.com>,
	"Gabriel Dos Reis" <gdr@integrable-solutions.net>,
	"Jonathan Wakely" <jwakely.gcc@gmail.com>,
	"gcc Mailing List" <gcc@gcc.gnu.org>
Subject: Re: Updated GCC vs Clang diagnostics
Date: Fri, 13 Apr 2012 20:59:00 -0000	[thread overview]
Message-ID: <CAGqM8fYY=iqgJofniekcnmM7d_RBfOjZUmCYyE5jFY5QXUCMhA@mail.gmail.com> (raw)
In-Reply-To: <mcrfwc89pwr.fsf@dhcp-172-18-216-180.mtv.corp.google.com>

On 4/12/12, Ian Lance Taylor <iant@google.com> 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.

Agreed, no one is suggesting that.

However, without care, the message might be harder to understand
_with_ color.  At a minimum, one should be able to turn the
color off.  As I understand it, that option is in the plan.

> 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.

Yes, color can enhance the messages.  I don't think we disagree
on that.  My point was that color is a harder problem that many
people understand.  For instance, there is no set of colors that
meet web contrast standards against both black and white backgrounds.

As I understand the plan, the colors will be user-configurable,
which goes a long way to addressing the problem because the user
can choose colors that work for them.  It would be nice if the
default configuration worked for a large set of folks.

> 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.

Let me try to be clear.  I have no objection to the work as long as
I can turn it off.  If the issues I mention above are unaddressed,
it is likely that I will turn it off, which is why the feature is
low on my list of desirables.  If other folks desire it, I'm happy
to let them have it.  I'm even happy to add an environment variable
so that they can have it.  But, responding to the survey question,
for me color is not a priority.

-- 
Lawrence Crowl

  parent reply	other threads:[~2012-04-13 20:59 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 21:50 Manuel López-Ibáñez
2012-04-12 21:54 ` Gabriel Dos Reis
2012-04-12 22:05   ` Manuel López-Ibáñez
2012-04-12 22:18     ` Gabriel Dos Reis
2012-04-12 22:43       ` Manuel López-Ibáñez
2012-04-13  1:40         ` Joe Buck
2012-04-13  2:27           ` Manuel López-Ibáñez
2012-04-13  3:37             ` Gabriel Dos Reis
2012-04-13  8:27               ` Manuel López-Ibáñez
2012-04-13  8:41                 ` Gabriel Dos Reis
2012-04-13  9:08                 ` Jonathan Wakely
2012-04-13  8:59           ` Jonathan Wakely
2012-04-13  9:04             ` Gabriel Dos Reis
2012-04-13 10:54               ` Manuel López-Ibáñez
2012-04-13 11:36                 ` Richard Guenther
2012-04-13 13:40                   ` Gabriel Dos Reis
2012-04-12 22:18     ` Lawrence Crowl
2012-04-13  5:12       ` Ian Lance Taylor
2012-04-13  5:58         ` Gabriel Dos Reis
2012-04-13  6:03         ` Jakub Jelinek
2012-04-13  6:07           ` Gabriel Dos Reis
2012-04-13  8:41           ` Manuel López-Ibáñez
2012-04-13  8:47             ` Gabriel Dos Reis
2012-04-13  9:00               ` Manuel López-Ibáñez
2012-04-13  9:09                 ` Gabriel Dos Reis
2012-04-13 14:23                   ` Jakub Jelinek
2012-04-13 15:23                     ` Gabriel Dos Reis
2012-04-13 15:30                       ` NightStrike
2012-04-13 15:36                         ` Gabriel Dos Reis
2012-04-13 15:41                           ` NightStrike
2012-04-13 15:53                             ` Gabriel Dos Reis
2012-04-13 15:59                               ` NightStrike
2012-04-13 16:02                                 ` Gabriel Dos Reis
2012-04-13 20:59         ` Lawrence Crowl [this message]
2012-04-14  6:58           ` Marc Glisse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGqM8fYY=iqgJofniekcnmM7d_RBfOjZUmCYyE5jFY5QXUCMhA@mail.gmail.com' \
    --to=crowl@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@integrable-solutions.net \
    --cc=iant@google.com \
    --cc=jwakely.gcc@gmail.com \
    --cc=lopezibanez@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).