mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2026-08-27 00:26:02 -04:00
e5348a7ab3
Currently, gdb.execute emits styled output when the command is sending its output to GDB's stdout, and produces unstyled output when the output is going to a string. But it is not unreasonable that a user might wish to capture styled output from a gdb.execute call, for example, the user might want to display the styled output are part of some larger UI output block. At the same time, I don't think it makes sense to always produce styled output when capturing the output in a string; if what the user wants is to parse the output, then the style escape sequences make this far harder. I propose that gdb.execute gain a new argument 'styling'. When False we would always produce unstyled output, and when True we would produce styled output if styling is not disabled by some other means. For example, if GDB's 'set style enabled' is off, then I think gdb.execute() should respect that. My assumption here is that gdb.execute() might be executed by some extension. If the extension thinks "styled output world work here", but the user hates styled output, and has turned it off, then the extension should not be forcing styled output on the user. I chose 'styling' instead of 'styled' as the Python argument name because we already use 'styling' in gdb.Value.format_string, and we don't use 'styled' anywhere else. This is only a little bit of consistency, but I still think it's a good thing. The default for 'styling' will change depending on where the output is going. When gdb.execute is sending the output to GDB's stdout then the default for 'styling' is True. When the output is going to a string, then the default for 'styling' will be False. Not only does this match the existing behaviour, but I think this makes sense. By default we assume that output captured in a string is going to be parsed, and therefore styling markup is unhelpful, while output going to stdout should receive styling. This fixes part of the problem described in PR gdb/32676. That bug tries to capture styled source listing in a string, which wasn't previously possible. There are some additional issues with capturing source code; GDB caches the source code in the source code cache. However, GDB doesn't check if the cached content is styled or not. As a consequence, if the first time the source of a file is shown it is unstyled, then the cached will hold the unstyled source code, and future requests will return that unstyled source. I'll address this issue in a separate patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676 Approved-By: Tom Tromey <tom@tromey.com> |
||
|---|---|---|
| .. | ||
| lib/gdb | ||
| py-all-events.def | ||
| py-arch.c | ||
| py-auto-load.c | ||
| py-block.c | ||
| py-bpevent.c | ||
| py-breakpoint.c | ||
| py-cmd.c | ||
| py-color.c | ||
| py-color.h | ||
| py-connection.c | ||
| py-continueevent.c | ||
| py-dap.c | ||
| py-disasm.c | ||
| py-event-types.def | ||
| py-event.c | ||
| py-event.h | ||
| py-events.h | ||
| py-evtregistry.c | ||
| py-evts.c | ||
| py-exitedevent.c | ||
| py-finishbreakpoint.c | ||
| py-frame.c | ||
| py-framefilter.c | ||
| py-function.c | ||
| py-gdb-readline.c | ||
| py-inferior.c | ||
| py-infevents.c | ||
| py-infthread.c | ||
| py-instruction.c | ||
| py-instruction.h | ||
| py-lazy-string.c | ||
| py-linetable.c | ||
| py-membuf.c | ||
| py-mi.c | ||
| py-micmd.c | ||
| py-newobjfileevent.c | ||
| py-objfile.c | ||
| py-param.c | ||
| py-prettyprint.c | ||
| py-progspace.c | ||
| py-record-btrace.c | ||
| py-record-btrace.h | ||
| py-record-full.c | ||
| py-record-full.h | ||
| py-record.c | ||
| py-record.h | ||
| py-ref.h | ||
| py-registers.c | ||
| py-signalevent.c | ||
| py-stopevent.c | ||
| py-stopevent.h | ||
| py-symbol.c | ||
| py-symtab.c | ||
| py-threadevent.c | ||
| py-tui.c | ||
| py-type.c | ||
| py-uiout.h | ||
| py-unwind.c | ||
| py-utils.c | ||
| py-value.c | ||
| py-varobj.c | ||
| py-xmethods.c | ||
| python-config.py | ||
| python-internal.h | ||
| python.c | ||
| python.h | ||