Re: [RFC 0/8] add terminal styling to gdb

[Tom Tromey <tom@tromey.com>]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> This series is not ready to review, but I wanted some feedback on the
Tom> general approach before committing to writing documentation, test
Tom> cases, and comments.

Tom> I've wanted gdb to use colors on the terminal for a while now.  I've
Tom> actually tried implementing this a few different ways at different
Tom> times, the most successful approach so far being a colorizing frame
Tom> filter.

Pedro asked on irc about a styling design closer to what lldb does.
That program lets the user customize the output of commands like 'bt',
by providing a format that is followed.  Adding colorizing to this is
just a matter of adding a color specification to the format.

I did consider a design like this for gdb.  In particular what I
looked at was adding format strings based on the existing ui-out code.
Then, cli-out would be changed to parse these strings, collect fields,
and then format the fields according to the format.  Finally, explicit
formatting at the call sites would be removed and replaced with the
appropriate default format strings.

This seemed like an attractive idea because ui-out is close to what we
would want here, and since the field names are already an advertised
API they could probably be presented to the user as well.

A super simple example that in this plan we could remove:

  uiout->text ("\n");

from print_one_bfd and replace it with a format like

  "{refcount<10}{addr<18}{filename<40}\n"

(Just one possible syntax.)

Table headers would be emitted using the same format.


A further idea in this plan was to get rid of is-mi-like-p tests in
favor of just emitting everything and letting the format simply not
print fields that were uninteresting.  This is harder, though, because
there are more special cases that would have to be handled.


However, I rejected this plan because some of the existing exceptions
to the general approach seemed ugly to deal with.  The formatting
string would have to be a mini language of its own in order to work.

* info_osdata emits a variable number of columns
* print_program_space prints extra information between rows
* breakpoint_1 conditionally emits a column based on whether
  addressprint is set

Also some of the table names or column names are poorly chosen.  I
suppose this could be handled by having some mapping in the CLI.


One thing I like about the approach I took in the current series is
that it allows for semantic styling.  That is, we can style filenames
the same way everywhere.  Also it can easily be done in situations
where gdb is not using ui-out.

Now, one way to handle this in the formatting scenario would be to
introduce formatting constructs to use semantic styling, like "start a
file name now" or whatever.  In this idea, though, the two approaches
are complementary and so we wouldn't need to decide now: we could move
forward with the series as-is and add formatting at a later stage.


Speaking of that, right now the semantic styling is actually done by
matching field names.  I wonder if ui-out should have new methods for
things like "field_filename" or whatever other "type" information we'd
like to associate.  Alternatively I wonder if the style should just be
passed as an optional argument to the various ui-out methods.

Tom