From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44061 invoked by alias); 12 Sep 2018 12:20:50 -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 44048 invoked by uid 89); 12 Sep 2018 12:20:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=listen, poster, refresh X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Sep 2018 12:20:48 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 93691402333A; Wed, 12 Sep 2018 12:20:46 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id E82C410CD6B7; Wed, 12 Sep 2018 12:20:45 +0000 (UTC) Subject: Re: [PATCH] Make "list" work again in TUI To: Tom Tromey References: <20180908143153.18583-1-tom@tromey.com> <87musq4jdk.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <66752a61-08f1-5588-691d-205e89b09471@redhat.com> Date: Wed, 12 Sep 2018 12:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87musq4jdk.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00354.txt.bz2 On 09/09/2018 07:26 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom Tromey writes: > > Tom> This patch makes the "list" command work again by adding some caching. > Tom> Now the TUI tracks the previously displayed frame, PC, and inferior; > Tom> and only updates the display if one of these was changed by the > Tom> previous command. > > I have a question about this one now. > > In the bug the original poster said that to get back to the current > location, he would use the "frame" command. This doesn't work with my > patch, and I'm not sure how it would have worked in the past. I used to do that too. > > One part of how the TUI links to the CLI is very convoluted -- there is > a special case in tui-out to notice how the "list" command emits fields > and newlines and to use that to refresh the window. I'd rather not do > anything this roundabout and fragile... Yeah. > > Other parts of the CLI use #ifdef TUI to decide what action to take when > the TUI is available. This seems like an "old school" approach though I > must say I prefer its directness. I wouldn't mind rewriting "list" to > do this. > > Another option might be to have the frame command unconditionally notify > some observer. Then the TUI could listen for this. > > Anyway, I'd appreciate comments on which approach CLI/TUI integration > ought to ideally take. I don't know the history here and there aren't > guiding comments that I could find. I'm under the impression that the TUI was added along with the major HP dump/merge back in the day, meaning original design history is probably lost. I may be wrong. Offhand, it seems to me that the TUI should update its listed source whenever the CLI's current source changes. I.e., the TUI's source window should be updated whenever set_current_source_symtab_and_line is used to update the current source & line for the CLI's "list". Which suggests that for "frame" TUI re-centering, an observer notification from within set_current_source_symtab_and_line would work. If we always updated the source window from a TUI observer for that notification, could we make tui_refresh_frame_and_register_information just never update the source window? I.e., remove the select_source_symtab call from tui_refresh_frame_and_register_information or something along those lines. That assumes that if the frame changed, then presumably, set_current_source_symtab_and_line will have already been called, which it seems is true. (if it isn't, then "list" won't be updated either, and we're back to the argument about keeping "list" and the TUI in sync.). That would eliminate the need for the caching. Thanks, Pedro Alves