Re: [PATCH 00/16] Add styling to the gdb CLI and TUI

[Eli Zaretskii <eliz@gnu.org>]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
> Date: Thu, 29 Nov 2018 15:43:59 -0700
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Will the Windows TUI build support styling out of the box?  It uses
> Eli> ncurses.
> 
> I think it should work, but you'd have to "set style enabled on" first.

Maybe a TUI invocation should "set style enabled on" on all platforms?
Or at least on those that use ncurses?

> Eli> And I don't think I understand what you mean by "filter escape
> Eli> sequences from the output".  Where (on what level) would such filter
> Eli> be installed, given that output is written directly to the console?
> 
> I think either utils.c would have to be modified to change where it
> sends output, or stdio_file::puts would have to be modified.  The idea
> there would be to call a host-specific function; and then on Windows do
> the filtering+styling if the output is going to the terminal.

Ouch!  I hoped we could avoid such kludges.  Although it could, of
course, be done, I did that at some point for Gnu Grep.  One problem
with this approach is that it needs to fix the escape sequences for
the relevant attributes, whereas AFAIU your code simply uses the
terminfo that happens to be in effect, is that right?

> Eli> I see that you introduced the emit_style_escape function that switches
> Eli> styles.  What I don't think I understand is whether it will work to
> Eli> have a Windows implementation of that that calls a function which
> Eli> causes the text output after that to use given colors?  It seems it
> Eli> will, because the code calls emit_style_escape before and after each
> Eli> string, but I cannot be sure.
> 
> Doing it that way can't work due to buffering.

Not sure I understand.  Console output is generally line-buffered, and
there's fflush to force writing any buffered output before applying
text attributes.  Am I missing something?

> Also, this approach would be undesirable anyway, because GNU Source
> Highlight emits escape codes -- that's why I abandoned my earlier
> plan of implementing styling as objects in the utils.c buffer.

What is GNU Source Highlight, and what is its relevance to the issue
at hand?

> Instead, I think filtering the escape sequences is really the only
> way.

The problem with that is that it hard-codes the SGR sequences concepts
right into the design, and the escape sequences are unknown in advance
on systems where there's no terminfo.

Thanks.