This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: color diagnostics markers
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Manuel López-Ibáñez <lopezibanez at gmail dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Apr 2013 04:26:37 -0500
- Subject: Re: RFC: color diagnostics markers
- References: <CAESRpQCG6VX4JTEXLhrV2LDCLENYB7i8ad-3jj=K6FGeuK5+Ug at mail dot gmail dot com> <20130402091449 dot GE20616 at tucnak dot redhat dot com>
On Tue, Apr 2, 2013 at 4:14 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with
> same syntax as e.g. GREP_COLORS, but with different names of the (two
> letter?) color names.
Agreed.
>> This patch only allows two options enable/disable colors (and defaults
>> to disabled), but grep has auto/never/always, and I can easily extend
>> the patch in that way.
>
> IMO we also want that autodetection and default to auto.
I disagree.
For this release, I think the default should be off. We need more
at least one major release in the wild before we decide on what
colors should be the default. (there is no reason why the default
should be biased towards light background as opposed to dark
background.)
Diagnostics have become unreadable largely because we have succumbed to the
idea that everything new should be on by default. These days, when I
may a simple mistakes where an argument isn't of the right type, I get
drawn under a deluge of explanatory notes supposed to help me understand
why a function and an implicit conversion to a type I never heard off was
not appropriate.
-- Gaby