This is the mail archive of the
mailing list for the Archer project.
Re: [python] how best to support colorized output? (with examplecolorized backtrace)
- From: Andrew Sutherland <sombrero at alum dot mit dot edu>
- To: archer at sourceware dot org
- Date: Thu, 26 Mar 2009 17:43:51 -0700
- Subject: Re: [python] how best to support colorized output? (with examplecolorized backtrace)
- References: <firstname.lastname@example.org> <email@example.com>
On 03/26/2009 05:18 PM, Tom Tromey wrote:
I think the only thing I would suggest would be to use the existing
filtering backtrace, and just reimplement colorization as a filter.
If that's not possible (I didn't dig into the details too much), let's
modify the existing Python backtrace command to make it possible :-)
Both the FilteringBacktrace class and its helper FrameWrapper class
directly write to an output stream as text devoid of any semantic
information. (They are using sys.stdout, though not always explicitly.)
It is hard to decorate this output without operating at the level of a
glorified colorizing regex.
I think something more along the line of a semantic stream (along the
lines of ui-out.h but perhaps more extensible) might work out, but could
be argued to be overkill.
For example, if the FrameWrapper did:
that would be wildly easier to colorize. The default stream would just
ignore the semantic info and dump things as strings. The colorizing
stream would have colors bound to certain types of things. I am
obviously glossing over where FILENAME AND LINENUMBER would come from.
Crossing into definite exciting overkill territory would be pushing the
invocations of the pretty printers into the smart stream itself. That
way the stream could perhaps do something even more clever than the
default pretty printer. And if the stream was part of a GUI it might be
able to establish some actionable linkage so you can right-click and
have relevant actions, etc.