From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46882 invoked by alias); 7 Sep 2018 14:36:15 -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 46868 invoked by uid 89); 7 Sep 2018 14:36:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cleaner X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.54.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Sep 2018 14:36:11 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 8F9F5400D2DA6 for ; Fri, 7 Sep 2018 09:36:10 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id yHrmf28RlkBj6yHrmfEDNT; Fri, 07 Sep 2018 09:36:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LjehNvJfQvI60AjuQwQWuZIbjmJ3wdbmCAKfwh6sdS4=; b=NrIXOvUxATGldBptGgUkiiYJY3 2rq56hCb6a9huxfKZW1zpQa5RXPQOqaRCEy3MFOKdhjMqK6ksJJKeG/y/sK6qVnlXj4m37ksnd0wo bv3XsARoF0YQO0cwp8AoQuL73; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:47948 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fyHrm-000PE2-AM; Fri, 07 Sep 2018 09:36:10 -0500 From: Tom Tromey To: Eli Zaretskii Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC 0/8] add terminal styling to gdb References: <20180906211303.11029-1-tom@tromey.com> <83r2i5vn9w.fsf@gnu.org> Date: Fri, 07 Sep 2018 14:36:00 -0000 In-Reply-To: <83r2i5vn9w.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 07 Sep 2018 09:23:39 +0300") Message-ID: <87h8j1xtly.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-09/txt/msg00119.txt.bz2 >>>>> "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. 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