Hi,
mcs (Mono's C# compiler) does color its errors: Colorful Error Output - Miguel de Icaza This looks very useful to me, are there plans to add something similar to clang?
Nico
This would be *very* nifty 
-Chris
And how will you solve it in a portable manner?
That's always the problem with console based colours.
And how will you solve it in a portable manner?
#if !defined(_WIN32) // ideally a more robust configure-based test
if (isatty(STDOUT_FILENO))
-Keith
Seems like it would have to be significantly more complex to know what escape sequences to use (eg by looking at $TERM).
Also, IDEs would probably want to disable colors even if they run the compiler hooked up to a pty, in favor of a builtin compiler neutral colorizer.
Seems like it would have to be significantly more complex to know what
escape sequences to use (eg by looking at $TERM).
The policy decisions can be made when the code exists :). It seems straight-forward to require users to set an envvar to get it or something, like the mono people did.
Also, IDEs would probably want to disable colors even if they run the
compiler hooked up to a pty, in favor of a builtin compiler neutral
colorizer.
This would only exist in the console-output diagnostics implementation. An IDE would use a separate implementation: we don't expect an IDE to be "parsing" the error/warning output of the compiler, it would just use the diagnostics reporting API natively.
-Chris
Hello, Everyone
My 2 cents:
Seems like it would have to be significantly more complex to know what
escape sequences to use (eg by looking at $TERM).
Maybe we can see, how the things are handled inside color-gcc?
A portable way to do this is to use llvm::sys::Process::StandardOutIsDisplayed(), which is implemented in terms of isatty on unix and does the right thing on win32.
-Chris
Seems like it would have to be significantly more complex to know what
escape sequences to use (eg by looking at $TERM).
Probably best to just use curses as an option for colorizing text. Then
it'll just work on almost every system.
Alternatively, I'm not personally aware of any system in use that LLVM
actually supports or plans to support that doesn't use the ANSI/VT100
color codes, so you could just go with that and make sure it can be
easily disabled just in case.
Seems like it would have to be significantly more complex to know what
escape sequences to use (eg by looking at $TERM).
The ANSI color escapes seem pretty standard. Do you know of a
terminal that uses a different set? There are definitely terminals
which don't support them at all, which might be more of an issue.
Also, IDEs would probably want to disable colors even if they run the
compiler hooked up to a pty, in favor of a builtin compiler neutral
colorizer.
Why would they run the compiler hooked up to a pty? Lots of unix
tools use the tty-ness of stdin/stdout to change their behavior (eg.
using interactive prompts), it seems like doing this would be a recipe
for disaster...
-Keith
Patch attached that does this:
http://onesadcookie.com/~keith/LookAtThePrettyColors.png
-Keith
colors.diff (2.64 KB)
I very much like the idea of colorized warnings myself. One thing I have hated about some command-line tools that allow colorized whatever is that they don't provide enough flexibility about changing the employed color scheme. For example, the colors to use on a white-on-black scheme are different than what would look good on a black-on-white scheme, etc. One possible solution is to allow users to specify colors via an environment variable.
Another detail that would be nice to automatically handle is when the user redirects compiler output to a file. In such cases, users rarely want to see the ANSI escape sequences (or whatever) including the logged output.
Oh, ah, I looked at the pretty colors... Nice...
const char *ansi_red = "...";
std::cerr << ansi_red;
would be easier to read.