From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32158 invoked by alias); 13 Nov 2012 07:36:49 -0000 Received: (qmail 31810 invoked by uid 22791); 13 Nov 2012 07:36:47 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qa0-f41.google.com (HELO mail-qa0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Nov 2012 07:36:41 +0000 Received: by mail-qa0-f41.google.com with SMTP id c26so176863qad.0 for ; Mon, 12 Nov 2012 23:36:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.42.8 with SMTP id q8mr22774188qae.77.1352792200415; Mon, 12 Nov 2012 23:36:40 -0800 (PST) Received: by 10.49.64.165 with HTTP; Mon, 12 Nov 2012 23:36:40 -0800 (PST) In-Reply-To: <874nkuddwl.fsf@fleche.redhat.com> References: <874nkuddwl.fsf@fleche.redhat.com> Date: Tue, 13 Nov 2012 07:36:00 -0000 Message-ID: Subject: Re: [PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode From: Stephane Carrez To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00305.txt.bz2 Tom, On Mon, Nov 12, 2012 at 4:44 PM, Tom Tromey wrote: > > I don't know this code at all, but I think checking immediate_quit here > is weird. Partly this is because I think most uses of immediate_quit in > gdb are incorrect, and I'd like to try to phase them out -- but having > the TUI depend on it makes this harder. Is there some other way to do > it? > > Tom I agree this is weird but I have not found any better solution without changing the core gdb. The problem is that the TUI must know that a gdb command is being executed. This way, if it interacts with the user, it has to be in the mode where a prompt is displayed. If we add some boolean predicate function that tells us we are executing some command (whatever the command, a user, a set, a show, ...) this would be fine for me. Some kind of 'is_executing_command_p'. Another way is to get an observer that allows the TUI to know when a command is finished. This way, it could do switch the TUI back to the SingleKey once the command is done. Adding an observer for this looks a little bit overkill. If anybody has a better solution, I would appreciate it too! Stephane