If TUI mode is enabled then coloring the prompt or output using escape sequences doesn't work, the sequences are instead shown as-is. Example: In normal mode, "echo \033[32mFOO\033[0m\n" will print "FOO" in green. However, if the TUI is enabled, it will print "^[[32mFOO^[[0m" instead. This makes trying to make the output more readable rather difficult.
\w is expanded to the working directory, the problem with TUI and extended-prompt are (only) the escape sequences. The proposed patch below just discards all non-printing characters, between \[ and \], in TUI mode. diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi index a2df254..cab10d2 100644 --- a/gdb/doc/python.texi +++ b/gdb/doc/python.texi @@ -5137,7 +5137,8 @@ Substitute the current working directory. Begin a sequence of non-printing characters. These sequences are typically used with the ESC character, and are not counted in the string length. Example: ``\[\e[0;34m\](gdb)\[\e[0m\]'' will return a -blue-colored ``(gdb)'' prompt where the length is five. +blue-colored ``(gdb)'' prompt where the length is five. In TUI mode +these characters are discarded. @item \] End a sequence of non-printing characters. @end table diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c index 97906ce..b77866a 100644 --- a/gdb/tui/tui-io.c +++ b/gdb/tui/tui-io.c @@ -232,6 +232,22 @@ tui_redisplay_readline (void) height = 1; for (in = 0; prompt && prompt[in]; in++) { + /* Drop characters from extended-prompt between \[ == \001 and \] = \002 + The point is, that waddch prints ^ instead of control characters and + in turn the latter are not interpreted by the terminal. TUI prints + then ^ and this is ugly. + + It seems there is no way to send escape characters to the terminal + under curses, at least not with fputc (c , stdout); + + Skiping escape sequences, which are not within \[ and \] is hard, as + only the terminal has knowledge where the sequence ends and where the + actual input starts. */ + if (prompt[in] == '\001') + { + do { in++; } while (prompt[in] != '\002' && prompt[in] != '\0'); + continue; + } waddch (w, prompt[in]); getyx (w, line, col); if (col <= prev_col)
I can think of two options here. One is to change the tui-out object to be able to parse terminal escape sequences. Then it could turn these into ncurses color calls. This seems like a pain but maybe it would not be too bad. The other is to change extended-prompt to have explicit color support and then change the TUI to understand that somehow. This route may not be so easy since normally gdb just prints whatever the python code gave it.
I'm working on a patch for this.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1d1d0bf76f3bc3056a1456e53c066f40ca4d0837 commit 1d1d0bf76f3bc3056a1456e53c066f40ca4d0837 Author: Tom Tromey <tom@tromey.com> Date: Mon Sep 3 12:42:59 2018 -0600 Make ANSI terminal escape sequences work in TUI PR tui/14126 notes that ANSI terminal escape sequences don't affect the colors shown in the TUI. A simple way to see this is to try the extended-prompt example from the gdb manual. Curses does not pass escape sequences through to the terminal. Instead, it replaces non-printable characters with a visible representation, for example "^[" for the ESC character. This patch fixes the problem by adding a simple ANSI terminal sequence parser to gdb. These sequences are decoded and those that are recognized are turned into the appropriate curses calls. The curses approach to color handling is unusual and so there are some oddities in the implementation. Standard curses has no notion of the default colors of the terminal. So, if you set the foreground color, it is not possible to reset it -- you have to pick some other color. ncurses provides an extension to handle this, so this patch updates configure and uses it when available. Second, in curses, colors always come in pairs: you cannot set just the foreground. This patch handles this by tracking actually-used pairs of colors and keeping a table of these for reuse. Third, there are a limited number of such pairs available. In this patch, if you try to use too many color combinations, gdb will just ignore some color changes. Finally, in addition to limiting the number of color pairs, curses also limits the number of colors. This means that, when using extended 8- or 24-bit color sequences, it may be possible to exhaust the curses color table. I am very sour on the curses design now. I do not know how to write a test for this, so I did not. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> PR tui/14126: * tui/tui.c (tui_enable): Call start_color and use_default_colors. * tui/tui-io.c (struct color_pair): New. (color_pair_map, last_color_pair, last_style): New globals. (tui_setup_io): Clean up color map when shutting down. (curses_colors): New constant. (get_color_pair, apply_ansi_escape): New functions. (tui_write): Rewrite. (tui_puts_internal): New function, from tui_puts. Add "height" parameter. (tui_puts): Use tui_puts_internal. (tui_redisplay_readline): Use tui_puts_internal. (_initialize_tui_io): New function. (color_map): New globals. (get_color): New function. * configure.ac: Check for use_default_colors. * config.in, configure: Rebuild.
Fixed.