From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111505 invoked by alias); 30 Apr 2018 18:52:34 -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 111280 invoked by uid 89); 30 Apr 2018 18:52:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cleaned, feeling X-HELO: gateway34.websitewelcome.com Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.148.164) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Apr 2018 18:52:32 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 70C7C2DAEBE for ; Mon, 30 Apr 2018 13:52:29 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id DDuXfuVP8QUwqDDuXfeTTp; Mon, 30 Apr 2018 13:52:29 -0500 X-Authority-Reason: nr=8 Received: from 97-122-176-117.hlrn.qwest.net ([97.122.176.117]:37814 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fDDuX-004MMl-0p; Mon, 30 Apr 2018 13:52:29 -0500 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 0/6] Remove some uses of is_mi_like_p References: <20180430140732.21601-1-tom@tromey.com> <5ff777cb-ce59-b818-d19f-60450e8fa414@redhat.com> Date: Mon, 30 Apr 2018 18:52:00 -0000 In-Reply-To: <5ff777cb-ce59-b818-d19f-60450e8fa414@redhat.com> (Pedro Alves's message of "Mon, 30 Apr 2018 19:36:28 +0100") Message-ID: <871sew4jdf.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1fDDuX-004MMl-0p X-Source-Sender: 97-122-176-117.hlrn.qwest.net (pokyo) [97.122.176.117]:37814 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-04/txt/msg00662.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I'm not sure what you mean exactly, but I've wished before that Pedro> we could write ui-out field output mixed in with plain text with Pedro> something like: Pedro> ui_out-> field_fmt (_("Field 1 is 0x%pF, at 0x%pF\n"), Pedro> ui_field_int ("field1", var1), Pedro> ui_field_func ("func_name", var2)); Pedro> That's allow proper i18n, and would allow things like colorizing. Pedro> I guess that this is something like what you mean, only you Pedro> probably have it more thought through. Haha, I wouldn't say that. What I was thinking, though, was a combination of: * teaching gdb to know when an escape sequence doesn't contribute to the column count (I have a patch for this); * moving all such formatting to a special formatting language; * and finally, letting users set the formats. So for the above example, the emission code would just look something like: ui_out->field_int ("field1", var1); ui_out->field_core_addr ("func_name", var2); Elsewhere the CLI would set up the default format for this table (or tuple or list): cli_out_register ("field-info-entry", "Field 1 is %{field1:x}, at %{field2:x}\n"); Colorizing could be done by just changing the format. Users could rearrange the columns or do other simple-ish customization as well. If we were feeling really ambitious we could replace annotations this way. I was also thinking that the column widths could be removed from the producers and put into these format strings. However, there are various tricky cases here, due to the ways that is_mi_like_p has been abused so far, and also the complicated ways that messages are actually constructed. I have a (partial) list on my other machine, if you really want to go into the weeds. Another idea I had was to do all this, only from Python. I have some code in this direction as well. However it seemed to me that, although Python would allow more flexibility (advanced users could program it), on the other hand it's better for the gdb core to be cleaned up if possible. Tom