From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8012 invoked by alias); 24 Jul 2002 16:50:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8005 invoked from network); 24 Jul 2002 16:50:18 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 24 Jul 2002 16:50:18 -0000 Received: from fleche.redhat.com (ta0207.peakpeak.com [204.144.244.207]) by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id KAA23208; Wed, 24 Jul 2002 10:50:12 -0600 Received: by fleche.redhat.com (Postfix, from userid 1000) id 498D14F832D; Wed, 24 Jul 2002 10:55:22 -0600 (MDT) To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: Patch: RFA: operate-and-get-next fix References: <87n0vtc1n2.fsf@creche.redhat.com> <15632.50715.850955.747717@localhost.redhat.com> <87y9c2573v.fsf@fleche.redhat.com> <15678.54268.874096.154108@localhost.redhat.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-Zippy: Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a plate of SAUCE MORNAY? Date: Wed, 24 Jul 2002 10:23:00 -0000 In-Reply-To: <15678.54268.874096.154108@localhost.redhat.com> Message-ID: <87it35ukud.fsf@fleche.redhat.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00481.txt.bz2 >>>>> "Elena" == Elena Zannoni writes: >> +/* This is like readline(), but it has some gdb-specific behavior. In >> + particular, if the user is in the middle of an >> + operate-and-get-next, we shuffle the hooks around so that the >> + expected result occurs. This is ugly, but it is inevitable given >> + that gdb switches between the two modes (async and not) of using >> + readline and that rl_pre_input_hook doesn't work properly in async >> + mode. */ Elena> Ok for the other changes, but I don't understand why you are Elena> setting rl_pre_input_hook in the async case, while in top.c Elena> there is a comment saying the opposite: The thing is, gdb uses both readline in both the synchronous and async modes during a single invocation. At the ordinary top-level prompt we might be using the async readline. That means we can't use rl_pre_input_hook, since it doesn't work properly in async mode. However, for a secondary prompt (" >", such as occurs during a `define'), gdb just calls readline() directly, running it in synchronous mode. So for operate-and-get-next to work in this situation, we have to switch the hooks around. That is what gdb_readline_wrapper is for. I thought the comment quoted above explained the situation. Apparently, though, it didn't. Can you suggest how I should change it to be more clear? I'll make the changes and resubmit the patch. Long term the best fix here, in my opinion, is to fix readline so that rl_pre_input_hook works properly in all situations. That code is pretty convoluted, though. When I looked at it (must have been a year ago now) it didn't look fun. Tom