[Bug c/45850] New: support color diagnostics

[Bug c/45850] New: support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

           Summary: support color diagnostics
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: manu@gcc.gnu.org


Support using color output to mark warnings/errors/notes.

Basically, clang's

-f[no-]color-diagnostics:
    This option, which defaults to on when a color-capable terminal is
detected, controls whether or not Clang prints diagnostics in color. When this
option is enabled, Clang will use colors to highlight specific parts of the
diagnostic.


Basis for implementation may be either diff or grep. It should be implemented
either in diagnostics.c or pretty-print.c (probably, diagnostics.c calling
pretty-print.c to enable/disable specific colors).

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr@integrable-solutions.ne
                   |                            |t

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 16:59:28 UTC ---
I would personally like to have this. I know most people that want this use a
wrapper around gcc (or have moved to clang), but the output of gcc is not
designed to be machine readable, so I think there is a benefit on implementing
this in GCC.

Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just
 color the diagnostic markers:

error: (bold red)
warning: (magenta)
note: (blue? green?)

I would follow the very simple implementation used by grep.

It will default to off of course, I don't plan to implement automatic detection
of capabilities or anything like that.

So before I waste my time, would such a thing be ever accepted in GCC?

[Bug c/45850] support color diagnostics

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-02 17:03:33 UTC ---
This is a dup of bug 36150.

*** This bug has been marked as a duplicate of bug 36150 ***

[Bug c/45850] support color diagnostics

[gdr@integrable-solutions.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #3 from Gabriel Dos Reis <gdr@integrable-solutions.net> 2010-10-02 17:30:05 UTC ---
On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850
>
> Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |gdr@integrable-solutions.ne
>                   |                            |t
>
> --- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 16:59:28 UTC ---
> I would personally like to have this. I know most people that want this use a
> wrapper around gcc (or have moved to clang), but the output of gcc is not
> designed to be machine readable,

I believe different people have different take on this.  I've seen
people argue and get stuff in on the basis that the output should
be machine readable.  I would suggest restraint from sweeping
statements, in the quest for consensus.

> so I think there is a benefit on implementing
> this in GCC.
>
> Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just
>  color the diagnostic markers:
>
> error: (bold red)
> warning: (magenta)
> note: (blue? green?)

my copy of GCC (under openSUSE) colors the output and let me
customize the colors.  That is quite system dependent.  Getting
the same stuff under non-Unix like system require more constraints
on the environment.  How far should we go to emulate an IDE?

[Bug c/45850] support color diagnostics

[gdr@integrable-solutions.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #4 from Gabriel Dos Reis <gdr@integrable-solutions.net> 2010-10-02 17:32:08 UTC ---
On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
> Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just
>  color the diagnostic markers:
>
> error: (bold red)
> warning: (magenta)
> note: (blue? green?)
>
> I would follow the very simple implementation used by grep.

IDEs let users get the colors they want -if they ever wanted.

(the above is certainly a wrong default for me -- the background
of my terminal is always dark. :-)

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 18:04:00 UTC ---
> my copy of GCC (under openSUSE) colors the output and let me
> customize the colors.  That is quite system dependent.  Getting
> the same stuff under non-Unix like system require more constraints
> on the environment.  How far should we go to emulate an IDE?

So how does it work in openSUSE? Do they have patches that FSF GCC doesn't
have?

I really don't care about non-unix environments. Not all features of GCC work
on all operating systems.

And you say that you have colored output but you don't want FSF GCC to have it?
Am I misunderstanding you?

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 18:30:45 UTC ---
(In reply to comment #4)
> On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
> 
> IDEs let users get the colors they want -if they ever wanted.

The output of GCC is not designed to be parsed by IDEs:

http://gcc.gnu.org/PR19165

nor is GCC designed to be tightly integrated with an IDE.

> (the above is certainly a wrong default for me -- the background
> of my terminal is always dark. :-)

It is readable in my black background. It also looks nice here:

http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/

and in the examples here:

http://llvm.org/devmtg/2009-10/StateOfClang.pdf

Those colors are also readable in a white background. But feel free to suggest
defaults, and I will be happy with them. Of course, customization, like grep,
and ls, could be added later.

[Bug c/45850] support color diagnostics

[gdr@integrable-solutions.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #7 from Gabriel Dos Reis <gdr@integrable-solutions.net> 2010-10-02 18:35:26 UTC ---
On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he
environment.  How far should we go to emulate an IDE?
>
> So how does it work in openSUSE? Do they have patches that FSF GCC doesn't
> have?

I did not look into their pacthes GC -- every vendor patches GCC in one
way or the other.

> I really don't care about non-unix environments. Not all features of GCC work
> on all operating systems.

I think that it a problem.


>
> And you say that you have colored output but you don't want FSF GCC to have it?
> Am I misunderstanding you?

I think you are.  I don't know if it is on purpose.

[Bug c/45850] support color diagnostics

[gdr@integrable-solutions.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #8 from Gabriel Dos Reis <gdr@integrable-solutions.net> 2010-10-02 18:41:28 UTC ---
On Sat, Oct 2, 2010 at 1:30 PM, manu at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850
>
> --- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 18:30:45 UTC ---
> (In reply to comment #4)
>> On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
>>
>> IDEs let users get the colors they want -if they ever wanted.
>
> The output of GCC is not designed to be parsed by IDEs:
>
> http://gcc.gnu.org/PR19165
>
> nor is GCC designed to be tightly integrated with an IDE.

that PR is a proof of what?

One reason we have standardized on 'warning: ', 'error: ', etc.
prefixes is precisely so that IDEs or other tools can differentiate
them.  The fact that we have not succeeded in many other areas
is more of a shortcoming than a design goal.

>> (the above is certainly a wrong default for me -- the background
>> of my terminal is always dark. :-)
>
> It is readable in my black background. It also looks nice here:

I think we may just have found two sets of people who disagree
on what is readable with a dark background.  Which is precisely
the point of my original message.

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 19:46:31 UTC ---
(In reply to comment #7)
> On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he
> environment.  How far should we go to emulate an IDE?
> >
> > So how does it work in openSUSE? Do they have patches that FSF GCC doesn't
> > have?
> 
> I did not look into their pacthes GC -- every vendor patches GCC in one
> way or the other.

I did. They don't have a patch for this so I really wonder how this is
possible. Are you sure you didn't install some wrapper around gcc?

Anyway, it is clear that is not something widely available. The fact that you
have it enabled and openSUSE supports this is an indication that it is a
desirable feature, at least for a subset of users.

> > I really don't care about non-unix environments. Not all features of GCC work
> > on all operating systems.
> 
> I think that it a problem.

Why? It only seems to work on openSUSE right now, definitely not in Ubuntu, so
extending it to all unix supported by FSF GCC seems an improvement to me.

> > And you say that you have colored output but you don't want FSF GCC to have it?
> > Am I misunderstanding you?
> 
> I think you are.  I don't know if it is on purpose.

I want to add a feature to the FSF GCC. You are the one that can allow it, but
you seem not in favour of it, despite using this feature in a customized
version of GCC. So it is definitely in my best interest to understand why this
is so, to try to address your concerns, or otherwise realize that this is not
possible at all and give up.

[Bug c/45850] support color diagnostics

[gdr@integrable-solutions.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #10 from Gabriel Dos Reis <gdr@integrable-solutions.net> 2010-10-02 22:35:12 UTC ---
On Sat, Oct 2, 2010 at 2:46 PM, manu at gcc dot gnu.org
>> > And you say that you have colored output but you don't want FSF GCC to have it?
>> > Am I misunderstanding you?
>>
>> I think you are.  I don't know if it is on purpose.
>
> I want to add a feature to the FSF GCC. You are the one that can allow it, but
> you seem not in favour of it,

You seem to equate `discussing the technical problems (because there
are) associated with this' with 'seem not to favour' to the point of
attributing claims I have not made to me.  That makes it difficult to
discern when you are discussing technical problem as opposed
anything else. It makes hard to listen to what you are saying.


> despite using this feature in a customized
> version of GCC. So it is definitely in my best interest to understand why this
> is so, to try to address your concerns, or otherwise realize that this is not
> possible at all and give up.

There is a difference between `asking question in order to understand'
and `making a claim and attributing it to me'.

[Bug c/45850] support color diagnostics

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-03 09:50:06 UTC ---
(In reply to comment #6)
> 
> The output of GCC is not designed to be parsed by IDEs:
> 
> http://gcc.gnu.org/��0��

As an aside, what happened to that URL?
It looks fine here:
http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg00243.html

Is this a bugzilla bug?

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-03 10:11:26 UTC ---
The output of GCC is not designed to be parsed by IDEs:

http://gcc.gnu.org/PR19165

nor is GCC designed to be tightly integrated with an IDE.

[Bug c/45850] support color diagnostics

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-03 10:12:27 UTC ---
(In reply to comment #11)
> 
> Is this a bugzilla bug?

It seems so, since I can make it happen again.

[Bug c/45850] support color diagnostics

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |LpSolit at netscape dot net

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-03 10:24:00 UTC ---
Frédéric, do you know what happened to the mangled URLs in this PR?

[Bug c/45850] support color diagnostics

[LpSolit at netscape dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850

--- Comment #15 from Frédéric Buclin <LpSolit at netscape dot net> 2010-10-03 13:09:08 UTC ---
(In reply to comment #14)
> Frédéric, do you know what happened to the mangled URLs in this PR?

Yes, this string has been linkified twice. First because the GCC extension
detected the "PR....." string, and second because Bugzilla detected the
"http://..." string. This is now fixed.