possible to show color message from compiler log message(ansi escape code)

[ollydbg]

Hi, I see a post:

Scintilla / Bugs / #2161 Ansi color codes support

I see that scintilla is already support such feature in year 2016, so maybe we can enable this feature(by parsing the ANSI escape code) in our C::B's compiler log message?

Any ideas?

[Pecan]

Wow! What a great idea. I've always wished for colors in the log.
Especially in the DebugLog() function. Green for ok; yellow for info; red for errors.

But for now, I'm swamped supporting TokenTree for LSP responses.

[oBFusCATed]

It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...

[Avan]

It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...

Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.

[ollydbg]

It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...

Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.

If the slow down is from the C::B side, how can we check it. Disable or Enable the reg expressing parser inside the compiler plugin?

[Avan]

Can't the process be run from the command line, without CB in memory?

[oBFusCATed]

Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.

The speed C::B displays warnings shouldn't be a motivator to solve them.
C::B should not be slow displaying warnings. This has nothing to do with the compiler getting slower if there are many warnings, it is just C::B getting slower processing them.

[Avan]

Would it then not help if C::B was slowed down even more? ;o)

I still think that suppressing and/or ignoring boatloads of warnings is not the way to develop software. If done wright the bottom line should/could read 0 error and 0 warnings.