Re: [RFA 0/6] Remove some uses of is_mi_like_p

[Tom Tromey <tom at tromey dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I'm not sure what you mean exactly, but I've wished before that
Pedro> we could write ui-out field output mixed in with plain text with
Pedro> something like:

Pedro> ui_out-> field_fmt (_("Field 1 is 0x%pF, at 0x%pF\n"),
Pedro>                      ui_field_int ("field1", var1),
Pedro>                      ui_field_func ("func_name", var2));

Pedro> That's allow proper i18n, and would allow things like colorizing.

Pedro> I guess that this is something like what you mean, only you
Pedro> probably have it more thought through.

Haha, I wouldn't say that.

What I was thinking, though, was a combination of:

* teaching gdb to know when an escape sequence doesn't contribute to the
  column count (I have a patch for this);
* moving all such formatting to a special formatting language;
* and finally, letting users set the formats.


So for the above example, the emission code would just look something
like:

   ui_out->field_int ("field1", var1);
   ui_out->field_core_addr ("func_name", var2);

Elsewhere the CLI would set up the default format for this table (or
tuple or list):

   cli_out_register ("field-info-entry",
                     "Field 1 is %{field1:x}, at %{field2:x}\n");

Colorizing could be done by just changing the format.  Users could
rearrange the columns or do other simple-ish customization as well.  If
we were feeling really ambitious we could replace annotations this way.

I was also thinking that the column widths could be removed from the
producers and put into these format strings.

However, there are various tricky cases here, due to the ways that
is_mi_like_p has been abused so far, and also the complicated ways that
messages are actually constructed.  I have a (partial) list on my other
machine, if you really want to go into the weeds.


Another idea I had was to do all this, only from Python.  I have some
code in this direction as well.  However it seemed to me that, although
Python would allow more flexibility (advanced users could program it),
on the other hand it's better for the gdb core to be cleaned up if
possible.

Tom