From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56559 invoked by alias); 9 Sep 2018 18:26:52 -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 56550 invoked by uid 89); 9 Sep 2018 18:26:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Then, history, notify, poster X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 09 Sep 2018 18:26:49 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 9260083915B for ; Sun, 9 Sep 2018 13:26:48 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id z4Q4fkBwHaSeyz4Q4fC9qt; Sun, 09 Sep 2018 13:26:48 -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=VxIaCk7otpiBzj9v6oH0VhWO4mWi8OoPMLiMnHQ1R+8=; b=M5n9zpxiu2bIofJE+1MMliEo1Y 7Rg6LcuZ3l/FPsbrN+bsF4MyF0Z3wYR4NTXrV+m3DKjUldDqpUbT2gMQwd8FKq/VmslhV5vt8sbuf jO2hhabp0IUyvfqNW//BccXzf; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:44164 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fz4Q4-002iHV-C1; Sun, 09 Sep 2018 13:26:48 -0500 From: Tom Tromey To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Make "list" work again in TUI References: <20180908143153.18583-1-tom@tromey.com> Date: Sun, 09 Sep 2018 18:26:00 -0000 In-Reply-To: <20180908143153.18583-1-tom@tromey.com> (Tom Tromey's message of "Sat, 8 Sep 2018 08:31:53 -0600") Message-ID: <87musq4jdk.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-09/txt/msg00239.txt.bz2 >>>>> "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. 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... 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. thanks, Tom