From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88983 invoked by alias); 4 Oct 2018 13:11:48 -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 88965 invoked by uid 89); 4 Oct 2018 13:11:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=presented, attractive, scenario, Finally X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.199.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 13:11:44 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 0B449400EFD49 for ; Thu, 4 Oct 2018 07:18:00 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 83Pqgs44daSey83PrgFDIm; Thu, 04 Oct 2018 08:11:43 -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=M02X6dNypRJhUjoaf8XPVZYPGnuHsfj0MsrrpwUnMUk=; b=fQLivH07ZzEZV7y7ikN9fCbXc3 125n6WztJgAhfXjJbWn0HhbWsJ9V1aoGcKf6q7qAghiVICJaMhCKIE5C2YBD22NO6kZ2dFKfG+jaa sVnDnGfXfw7xnMMKlpJI23eUt; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:37818 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g83Pq-003kl6-Pf; Thu, 04 Oct 2018 08:11:42 -0500 From: Tom Tromey To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC 0/8] add terminal styling to gdb References: <20180906211303.11029-1-tom@tromey.com> Date: Thu, 04 Oct 2018 13:11:00 -0000 In-Reply-To: <20180906211303.11029-1-tom@tromey.com> (Tom Tromey's message of "Thu, 6 Sep 2018 15:12:55 -0600") Message-ID: <87woqxg8ky.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-10/txt/msg00107.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> This series is not ready to review, but I wanted some feedback on the Tom> general approach before committing to writing documentation, test Tom> cases, and comments. Tom> I've wanted gdb to use colors on the terminal for a while now. I've Tom> actually tried implementing this a few different ways at different Tom> times, the most successful approach so far being a colorizing frame Tom> filter. Pedro asked on irc about a styling design closer to what lldb does. That program lets the user customize the output of commands like 'bt', by providing a format that is followed. Adding colorizing to this is just a matter of adding a color specification to the format. I did consider a design like this for gdb. In particular what I looked at was adding format strings based on the existing ui-out code. Then, cli-out would be changed to parse these strings, collect fields, and then format the fields according to the format. Finally, explicit formatting at the call sites would be removed and replaced with the appropriate default format strings. This seemed like an attractive idea because ui-out is close to what we would want here, and since the field names are already an advertised API they could probably be presented to the user as well. A super simple example that in this plan we could remove: uiout->text ("\n"); from print_one_bfd and replace it with a format like "{refcount<10}{addr<18}{filename<40}\n" (Just one possible syntax.) Table headers would be emitted using the same format. A further idea in this plan was to get rid of is-mi-like-p tests in favor of just emitting everything and letting the format simply not print fields that were uninteresting. This is harder, though, because there are more special cases that would have to be handled. However, I rejected this plan because some of the existing exceptions to the general approach seemed ugly to deal with. The formatting string would have to be a mini language of its own in order to work. * info_osdata emits a variable number of columns * print_program_space prints extra information between rows * breakpoint_1 conditionally emits a column based on whether addressprint is set Also some of the table names or column names are poorly chosen. I suppose this could be handled by having some mapping in the CLI. One thing I like about the approach I took in the current series is that it allows for semantic styling. That is, we can style filenames the same way everywhere. Also it can easily be done in situations where gdb is not using ui-out. Now, one way to handle this in the formatting scenario would be to introduce formatting constructs to use semantic styling, like "start a file name now" or whatever. In this idea, though, the two approaches are complementary and so we wouldn't need to decide now: we could move forward with the series as-is and add formatting at a later stage. Speaking of that, right now the semantic styling is actually done by matching field names. I wonder if ui-out should have new methods for things like "field_filename" or whatever other "type" information we'd like to associate. Alternatively I wonder if the style should just be passed as an optional argument to the various ui-out methods. Tom