On Sun, Apr 14, 2013 at 4:53 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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).
Everybody has got strong opinions, especially those who are eager to label others as having one. > Defining a variable in my environment counts as a clear intention. If you invoke GCC on command line with explicit option requesting colors, I don't think there is any doubt that. However, I dispute the intent to be so universally clear for most GCC users who happen to have GCC_COLORS set -- most users inherit whatever their sysadmin or distros set for them. That said, I am fine with the idea to GCC_COLORS => detect. -- Gaby
