From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78312 invoked by alias); 8 Oct 2018 11:10:46 -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 78298 invoked by uid 89); 8 Oct 2018 11:10:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=coloring, styling X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Oct 2018 11:10:43 +0000 Received: by simark.ca (Postfix, from userid 112) id 0178C1EA6B; Mon, 8 Oct 2018 07:10:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1538997042; bh=mykwTvoS2ADjP9xy03zgMtgMPXUqFvYRPvvQxkuYabg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=n62X4vVTtr7p6Q6AaZPf1eQ9QETf51jEXv1/5ZE4Xt0kb3+OS8tSaDBPA8wELT3rM mhKNhdLOt54Zza1GqLvwOACby2eEoX4zARX0A8h/eQm0t/QWTLrSXb9oC5iGGnOuAy YNIq71urTvFsScRu8xOXIhhrNDMwV0fDzbw7YyS0= Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 4A8581E52B; Mon, 8 Oct 2018 07:10:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=simark.ca; s=mail; t=1538997040; bh=mykwTvoS2ADjP9xy03zgMtgMPXUqFvYRPvvQxkuYabg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GzGC9p1Q/Swdq9ExuZmjcxfLUUPhSqYHPrbzQWOupmPD1k5aAtWGZHqkkDbwN4zdp qudZgoTGTU3W9/E+c/dwtCaV5MBz2V/7f+4L1Psk3ZwhRGXG/Q5ugzoAm0SJNyIY58 5gQwz9vPQrngykhr6FsD1Yrj2gyWVqYArzRHwrOM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 Oct 2018 11:10:00 -0000 From: Simon Marchi To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC 3/8] Add output styles to gdb In-Reply-To: <87lg79cfup.fsf@tromey.com> References: <20180906211303.11029-1-tom@tromey.com> <20180906211303.11029-4-tom@tromey.com> <87va6eevyo.fsf@tromey.com> <87pnwlcmmj.fsf@tromey.com> <87lg79cfup.fsf@tromey.com> Message-ID: X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2018-10/txt/msg00171.txt.bz2 On 2018-10-07 22:49, Tom Tromey wrote: >>>>>> "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. Do we pass in the values as with printf? Something like ui_out->format ("{refcount<10}{addr<18}{filename<40}\n", refcount, addr, filename); How does the underlying implementation of format knows that the refcount variable is an int, and that addr and filename are char*? We go by field name too? Or should the format specifier contain the data type? > 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. I tend to think that introducing a format-based system like this is relatively orthogonal to the coloring/styling issue. I see it as syntactic sugar over the field_* methods. Something would parse that format string and do the appropriate field_* calls for you under the hood. If we color based on field names, as the current patch does, then it wouldn't make any difference. If we provide a way for the caller to override the element type (on which the color/style choice is based), then we need to consider that in the format string syntax. If field "foo" is a filename, we can have something like "{foo<40:filename}" So my opinion is that introducing something like this isn't in the way of introducing coloring with the current system. Simon