[RFC 0/8] add terminal styling to gdb

Eli Zaretskii eliz@gnu.org
Fri Sep 7 14:56:00 GMT 2018


> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
> Date: Fri, 07 Sep 2018 08:36:09 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> This is a worthy goal, IMO, but please allow a level of abstraction
> Eli> between output styles and ANSI escape sequences.  In particular, the
> Eli> assumption that changing a style or switching text attributes (like
> Eli> color, bold, etc.) requires to "emit" something to the terminal, is
> Eli> not necessarily true.  Please allow for terminals where doing that
> Eli> requires a function call that doesn't necessarily write anything to
> Eli> the terminal.
> 
> I assume you're talking about Windows here.

Yes, and there's also go32 (a.k.a. DJGPP, a.k.a. MSDOS).

> I don't know anything about Windows -- could you explain a bit about
> what's needed to support it?

To change the visual appearance of the following text, such as colors
or standout, you need to call a function.  then you write text as
usual, with printf etc., and it appears with the attributes requested
by that function call.  Then, when you want to get back to the
defaults, you need to call the same function again, but with a
different argument.  The argument tells what video attributes shall be
turned on or off.

If you want a working example, you can look at pcterm.c in the
Texinfo's info/ directory, it is used for the stand-alone Info reader.

> I can't implement it but I could probably rework the low-level code --
> the stuff that interacts with the pager and line wrap buffering -- to
> let the stylizing be done in a host-dependent way.

Yes, that's what I was asking for.  The actual implementation should
come from someone else (perhaps myself ;-).

> One idea would be to have the line-wrap buffer be a vector that
> alternates strings and styles.  Then the terminal-specific output
> functions could apply styles in whatever way is appropriate.  Would this
> work for Windows?

Sorry, I don't think I follow.  What is the line-wrap buffer, and how
is it related to the issue at hand?

> Eli> Finally, did you consider the use case of running GDB from Emacs (via
> Eli> the old GUD, which uses CLI I/O)?  Would the color escapes be disabled
> Eli> in that case, or would that require Emacs to interpret them?  Same
> Eli> question for other front-ends which use CLI, if there are such.
> 
> Based on experience with my colorizing frame filter, it should all be
> fine.
> 
> First, looking at gdb in Emacs right now, I see:
> 
>     (top-gdb) show env TERM
>     TERM = dumb
> 
> My patches use this to disable colorizing.
> 
> That's not the end of the story though.  comint.el puts
> ansi-color-process-output onto comint-output-filter-functions by
> default.  So, I think we could have gdb look at getenv("INSIDE_EMACS")
> and re-enable the colorizing by default.

Yes, I agree on both counts.

(I presume this feature is just for CLI, not for the MI output,
right?)

Thanks.



More information about the Gdb-patches mailing list