Re: [RFC 3/8] Add output styles to gdb

[Simon Marchi <simark@simark.ca>]

On 2018-10-07 22:49, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> Ok, so I'd like to understand better the idea of the 
> format-based
> Simon> approach, maybe I don't quite get what you mean.  It would be 
> easier
> Simon> to comment on something concrete (even without code, just a 
> relatively
> Simon> well-defined description of the format).
> 
> The minimum, I think, is to have something that encompasses the
> formatting, but not the titling, emitted by table headers.  So instead
> of:
> 
>   uiout->table_header (10, ui_left, "refcount", "Refcount");
> 
> the example I gave said
> 
>   "{refcount<10}"
> 
> where the idea is that "refcount" is the field name, "<" says to
> left-justify, and "10" is the field size.  I pictured using ">" for
> right justification, and something like "|" for center and ":" or "="
> for "none".
> 
> Anything outside of {} would be plain text that is just emitted
> directly.

Do we pass in the values as with printf?  Something like

   ui_out->format ("{refcount<10}{addr<18}{filename<40}\n", refcount, 
addr, filename);

How does the underlying implementation of format knows that the refcount 
variable is an int, and that addr and filename are char*?  We go by 
field name too?  Or should the format specifier contain the data type?

> Exactly how to spell the formatting can be debated, like should there
> be a lead-in character ("set extended-prompt" uses backslash, C uses 
> %).
> 
> So, something like maintenance_info_bfds currently reads:
> 
>   ui_out_emit_table table_emitter (uiout, 3, -1, "bfds");
>   uiout->table_header (10, ui_left, "refcount", "Refcount");
>   uiout->table_header (18, ui_left, "addr", "Address");
>   uiout->table_header (40, ui_left, "filename", "Filename");
> 
> ... but in the format approach the first 2 arguments of each call could
> be removed.
> 
> Then when printing the body:
> 
>   ui_out_emit_tuple tuple_emitter (uiout, NULL);
>   uiout->field_int ("refcount", gdata->refc);
>   uiout->field_string ("addr", host_address_to_string (abfd));
>   uiout->field_string ("filename", bfd_get_filename (abfd));
>   uiout->text ("\n");
> 
> Here the ->text call could be removed and the text put into the format
> string.
> 
> 
> I didn't do an exhaustive survey of lists or tuples in the way that I
> looked at tables.  There are probably difficult cases lurking in there,
> just as there were for tables.  And, the difficult table cases remain
> unsolved -- I haven't really given them much thought.
> 
> Maybe another tricky case is handling indentation of elided stack
> frames.
> 
> 
> Something I like about the approach I implemented is that it's
> relatively easy to explain and use.
> 
> The upside of the foramtting approach is that it gives more power to
> users.  For example maybe there are things that are currently hidden
> behind mi-like-p that could be exposed; or at least users could arrange
> to drop fields they are not interested in.

I tend to think that introducing a format-based system like this is 
relatively orthogonal to the coloring/styling issue.  I see it as 
syntactic sugar over the field_* methods.  Something would parse that 
format string and do the appropriate field_* calls for you under the 
hood.  If we color based on field names, as the current patch does, then 
it wouldn't make any difference.  If we provide a way for the caller to 
override the element type (on which the color/style choice is based), 
then we need to consider that in the format string syntax.  If field 
"foo" is a filename, we can have something like

     "{foo<40:filename}"

So my opinion is that introducing something like this isn't in the way 
of introducing coloring with the current system.

Simon