From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41695 invoked by alias); 7 Sep 2018 14:56:10 -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 41674 invoked by uid 89); 7 Sep 2018 14:56:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= 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, 07 Sep 2018 14:56:08 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyIAz-0007vL-Bo for gdb-patches@sourceware.org; Fri, 07 Sep 2018 10:56:05 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyIAz-0007uS-6j; Fri, 07 Sep 2018 10:56:01 -0400 Received: from [176.228.60.248] (port=4190 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fyIAy-0005uu-IE; Fri, 07 Sep 2018 10:56:01 -0400 Date: Fri, 07 Sep 2018 14:56:00 -0000 Message-Id: <83va7htkzj.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <87h8j1xtly.fsf@tromey.com> (message from Tom Tromey on Fri, 07 Sep 2018 08:36:09 -0600) Subject: Re: [RFC 0/8] add terminal styling to gdb References: <20180906211303.11029-1-tom@tromey.com> <83r2i5vn9w.fsf@gnu.org> <87h8j1xtly.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-09/txt/msg00120.txt.bz2 > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org > Date: Fri, 07 Sep 2018 08:36:09 -0600 > > >>>>> "Eli" == Eli Zaretskii 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.