This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC 0/8] add terminal styling to gdb


>>>>> "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.  I don't know anything about
Windows -- could you explain a bit about what's needed to support it?

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.

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?

Eli> Another, perhaps alternative possibility, would be to use
Eli> curses/ncurses features for controlling text color.

Yeah.  I wrote some curses code for this for the TUI.  We could reuse
this when the TUI is available, but since gdb doesn't require curses
currently, this couldn't be the only approach.

It'd be cleaner if each ui-out handled this, so the TUI could implement
styles directly, but there is a layering problem where the pager needs
understand styles, and the pager is beneath ui-out.

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.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]