------- Comment #5 from pva at gentoo dot org 2008-05-06 18:07 ------- Andrew, it's very pity to see this bug closed as invalid so fast. Besides being useful, people enjoy colors and people work with compilers...
I've already stated that, but I repeat. colorgcc does not work in case you have localized output (see our bug report). Reading source of colorgcc it seems that it uses words like "warning" or error as a key to parse and colorize output. Thus taking into account the number of human languages gcc is translated to and will be in future, adding complexity of having different encodings leaves colorgcc hardly working without "fixing it with rasp-file" after translation updates or additions. The complexity of this makes me think that it's natural to have this feature in place where error/warning is thrown - that is in gcc itself... bug 36150 although could help, as it makes possible to parse error based on numbers, works only for languages with stable "references" where it's hardly possible that numbers changes, as in other case wrong coloring could mislead programmer... Summarizing, I do not see why decision error or warning we have should be decided based on output after gcc and not in first place - in gcc itself - where it's known with high certainty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
