From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75514 invoked by alias); 30 Nov 2018 07:02:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 75505 invoked by uid 89); 30 Nov 2018 07:02:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=hoped X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Nov 2018 07:02:52 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gScp4-000666-Au for gdb-patches@sourceware.org; Fri, 30 Nov 2018 02:02:50 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gScp4-00065w-77; Fri, 30 Nov 2018 02:02:46 -0500 Received: from [176.228.60.248] (port=2244 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gScp3-0002av-SK; Fri, 30 Nov 2018 02:02:46 -0500 Date: Fri, 30 Nov 2018 07:02:00 -0000 Message-Id: <83r2f3caje.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <8736rja4i8.fsf@tromey.com> (message from Tom Tromey on Thu, 29 Nov 2018 15:43:59 -0700) Subject: Re: [PATCH 00/16] Add styling to the gdb CLI and TUI References: <20181128001435.12703-1-tom@tromey.com> <83k1kxfzwo.fsf@gnu.org> <8736rja4i8.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00563.txt.bz2 > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org > Date: Thu, 29 Nov 2018 15:43:59 -0700 > > >>>>> "Eli" == Eli Zaretskii 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.