From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100642 invoked by alias); 8 Oct 2018 22:17:25 -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 100630 invoked by uid 89); 8 Oct 2018 22:17:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cli-out, cliout, ui-out, nope X-HELO: gateway34.websitewelcome.com Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.148.204) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Oct 2018 22:17:22 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 214F3269C25 for ; Mon, 8 Oct 2018 17:17:09 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 9dprgFUayBcCX9dpsgYbnz; Mon, 08 Oct 2018 17:17:08 -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=6uBlk4JAckHnT1otM1EqmhY3eSWAjaSYxGuj4ZAYxuE=; b=fBz0Ug6tR9QeQ5hiWVXEnmjTPh rFnVNq1yGrC6q54Tk3P8NJWlJhN08J1vizuY08lLcoVWDTFpzoCnxFT9soTMGh8mHlY6HqNnHum1c 38mFL5zi+2bZIV8XGM/cXarxz; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:51496 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g9dpr-0014yr-1p; Mon, 08 Oct 2018 17:17:07 -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> <87lg79cfup.fsf@tromey.com> Date: Mon, 08 Oct 2018 22:17:00 -0000 In-Reply-To: (Simon Marchi's message of "Mon, 08 Oct 2018 07:10:40 -0400") Message-ID: <87d0skccda.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/msg00199.txt.bz2 >>>>> "Simon" == Simon Marchi writes: >> "{refcount<10}" Simon> Do we pass in the values as with printf? Something like Simon> ui_out-> format ("{refcount<10}{addr<18}{filename<40}\n", refcount, Simon> addr, filename); Nope, the idea is to continue to use the existing ui-out methods. So continuing the gdb_bfd example, this code in print_one_bfd: uiout->field_int ("refcount", gdata->refc); uiout->field_string ("addr", host_address_to_string (abfd)); uiout->field_string ("filename", bfd_get_filename (abfd)); ... would not change at all. The idea is that the format would be registered as a set/show command somewhere. For tables, cli-out could look up the appropriate format string using the table name; not sure how tuples or lists would work. Simon> How does the underlying implementation of format knows that the Simon> refcount variable is an int, and that addr and filename are char*? We Simon> go by field name too? Or should the format specifier contain the data Simon> type? The above answers, but basically it would work like today -- the type is implicit in the ui-out calls, though really at the bottom layer it is all just strings. Simon> I tend to think that introducing a format-based system like this is Simon> relatively orthogonal to the coloring/styling issue. Part of the overall idea was to let users put styling directly in the format strings -- sorry, maybe I didn't really spell this out. So another example would be "{fg=red}{field<40}{fg=default}" ... or something along those lines. This would conflict a bit with the idea of styling elements the way that the current patch does it, since then you'd have to decide what takes precedence. Though, your note makes me think that this potential conflict really isn't so bad and we could push forward with the current approach and deal with more customizable formatting later. Tom