This is the mail archive of the
mailing list for the GDB project.
Re: ui_out format strings for fields and styles (Re: [PATCH] Style "pwd" output)
- From: Tom Tromey <tom at tromey dot com>
- To: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- Cc: Tom Tromey <tom at tromey dot com>, Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 03 Jul 2019 06:11:12 -0600
- Subject: Re: ui_out format strings for fields and styles (Re: [PATCH] Style "pwd" output)
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Philippe> If we have some markers/brackets in the format string to apply
Philippe> style, why do we keep the style as an additional parameter of
Philippe> the 'printf' like functions ?
Philippe> E.g. when looking at pango markup, changing the 'style' is done inside the string,
Philippe> such as :
Philippe> "<span foreground=red>some string with red foreground</span>"
Philippe> So, for GDB, we could have something like:
Philippe> some_output_function ("The filename is <style=filename>%s</style>.", some_filename);
Philippe> where the low level of some_output_function would translate the <style=..> into
Philippe> the real output of the control characters to do the styling.
Philippe> The advantage of this approach is that the styling can be added for example
Philippe> in the doc strings either statically and/or built dynamically
Philippe> (think for example to the new option framework that builds a part of the doc
Philippe> string: we might e.g. put in bold the part of the option that is 'unique').
I hadn't really given it much thought.
I suppose the main thing is that the lower levels -- ui-out and ui-file
-- are used for all output in gdb. So if we had some kind of markup in
the output, we'd need to find all the places emitting unpredictable
output (say, file names or data from the inferior) and arrange for those
to quote the output somehow, to prevent unwanted effects.
On the other hand the programmatic approach doesn't require this, and is
closer to what gdb already does.
Nothing precludes us from doing this later on. For instance, it could
be done for "help" without touching the rest of gdb.