From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27443 invoked by alias); 8 Oct 2018 02:49:39 -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 27428 invoked by uid 89); 8 Oct 2018 02:49:38 -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=exposed, tricky, tuple_emitter, uiout X-HELO: gateway33.websitewelcome.com Received: from gateway33.websitewelcome.com (HELO gateway33.websitewelcome.com) (192.185.145.23) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Oct 2018 02:49:36 +0000 Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 7830E1F06F for ; Sun, 7 Oct 2018 21:49:35 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 9LbzgqOfmSjJA9LbzgNmv4; Sun, 07 Oct 2018 21:49:35 -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=yzaPxOK1xNstA2L9b/7Wm8DKdQUi6Jq5CmICflkGGrc=; b=VuSRHiwErtTvAuAzZqIpevPcN0 Rm3D7bk1+4SQ+l3EUcTxfcJ2Dpvu8lF8hDIDZFvOxxavfoCfbb5FPRcQ3swMJignHAI1MQhEuCZWv 3S3Vq1fMRorfNLyDpgq+HCRc+; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:49732 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g9Lbz-000uvw-5h; Sun, 07 Oct 2018 21:49:35 -0500 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC 3/8] Add output styles to gdb References: <20180906211303.11029-1-tom@tromey.com> <20180906211303.11029-4-tom@tromey.com> <87va6eevyo.fsf@tromey.com> <87pnwlcmmj.fsf@tromey.com> Date: Mon, 08 Oct 2018 02:49:00 -0000 In-Reply-To: (Simon Marchi's message of "Sun, 07 Oct 2018 22:02:05 -0400") Message-ID: <87lg79cfup.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/msg00168.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> Ok, so I'd like to understand better the idea of the format-based Simon> approach, maybe I don't quite get what you mean. It would be easier Simon> to comment on something concrete (even without code, just a relatively Simon> well-defined description of the format). The minimum, I think, is to have something that encompasses the formatting, but not the titling, emitted by table headers. So instead of: uiout->table_header (10, ui_left, "refcount", "Refcount"); the example I gave said "{refcount<10}" where the idea is that "refcount" is the field name, "<" says to left-justify, and "10" is the field size. I pictured using ">" for right justification, and something like "|" for center and ":" or "=" for "none". Anything outside of {} would be plain text that is just emitted directly. Exactly how to spell the formatting can be debated, like should there be a lead-in character ("set extended-prompt" uses backslash, C uses %). So, something like maintenance_info_bfds currently reads: ui_out_emit_table table_emitter (uiout, 3, -1, "bfds"); uiout->table_header (10, ui_left, "refcount", "Refcount"); uiout->table_header (18, ui_left, "addr", "Address"); uiout->table_header (40, ui_left, "filename", "Filename"); ... but in the format approach the first 2 arguments of each call could be removed. Then when printing the body: ui_out_emit_tuple tuple_emitter (uiout, NULL); uiout->field_int ("refcount", gdata->refc); uiout->field_string ("addr", host_address_to_string (abfd)); uiout->field_string ("filename", bfd_get_filename (abfd)); uiout->text ("\n"); Here the ->text call could be removed and the text put into the format string. I didn't do an exhaustive survey of lists or tuples in the way that I looked at tables. There are probably difficult cases lurking in there, just as there were for tables. And, the difficult table cases remain unsolved -- I haven't really given them much thought. Maybe another tricky case is handling indentation of elided stack frames. Something I like about the approach I implemented is that it's relatively easy to explain and use. The upside of the foramtting approach is that it gives more power to users. For example maybe there are things that are currently hidden behind mi-like-p that could be exposed; or at least users could arrange to drop fields they are not interested in. Tom