On Wed, 10 Apr 2013, Gabriel Dos Reis wrote:
On Wed, Apr 10, 2013 at 1:42 PM, Manuel López-Ibáñez
<lopeziba...@gmail.com> wrote:
On 9 April 2013 15:21, Jakub Jelinek <ja...@redhat.com> wrote:
white). The default is still -fdiagnostics-color=never, can be changed
later on.
Apart from my comments elsewhere
(http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00614.html), the patch
looks fine to me. But perhaps we should change the default to auto, at
least during Stage 1, to find out whether some bug was introduced. If
agreed, I could do this in a follow-up patch that also disables colors
for the testsuite.
Cheers,
Manuel.
I am still of the opinion that the default should be discussed differently,
and I strongly suggest that it defaults to "never". I do not believe we do
need to do otherwise now.
As I stated before, our pursuit of enabling everything new thing by default
may have made C++ diagnostics more terrifying.
Hello,
I would like to suggest that the default be "auto" when the environment
variable GCC_COLORS is defined. It can stay "never" otherwise (I would
prefer "auto" as well, colors don't make the diagnostics any longer, only
more readable, and an empty GCC_COLORS is an easy way to disable them, but
I see you have a strong opinion on this so I won't insist).
Defining a variable in my environment counts as a clear intention. And
without it, if I want to always use colors, I need to either type the
option every time, or create wrappers for every version of every front-end
that I use.
For grep, I can have colors by default with GREP_OPTIONS=--color=auto. Any
alternative mean to enable colors by default would be ok with me.
By the way, I was unlucky enough to try colors by compiling a non-existing
file, but this message doesn't get any colors:
g++: error: zz.cc: No such file or directory
g++: fatal error: no input files
(not that it needs them, it is short enough)
--
Marc Glisse