I definitely believe this could be implemented differently… it would be horrible if colorized versions of commands always ended up being hacked up variants of the base command with colorization added in.

Of course, my differently would probably be a wildly over-engineered approach where everything is emitted to a stream as a type, which by default just does a simple str(). The colorizing output would look at the types as they went by and wrap the str() in the color assigned to the item. This would allow for UI’s where the semantic information is not lost on display, allowing useful right-click info, etc.

The problem with that approach, in my mind, is that it seems contrary to the existing pretty-printer mechanism. I’d expect Tom Tromey’s solution is probably far more pragmatic and likely to be adopted

PS1: We are still sorting out how to actually ship Python code in an official GDB release, so that may not happen before 7.0 goes out.

PS2: I don’t think we’ll be able to merge upstream everything you need to implement a backtrace command in Python, so it’s not likely your script would work/ship with GDB 7.0, but most certainly would with GDB 7.1. But who knows, perhaps we can merge all the dependencies in time for 7.0… I’ll certainly try to do that.

PS3: Tom Tromey also saw this, and he suggested that a coloured backtrace could be implemented a little bit differently, so you may expect some rework before your code would enter the Archer branch and GDB upstream…

That is so awesome, i have dreamed of such a thing for months
The problem is, that I don’t use gdb so often to be sure, if i’ll take the work needed to set that up, but it’s really great! I wished gdb supported an –color option, as it’s really impossible to grep monochrome text quickly