From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12782 invoked by alias); 5 Jun 2008 19:46:18 -0000 Received: (qmail 12763 invoked by uid 22791); 5 Jun 2008 19:46:16 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 19:45:56 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id C3FD5983F8; Thu, 5 Jun 2008 19:45:54 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 606719809F; Thu, 5 Jun 2008 19:45:54 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1K4LPF-0000LK-Jy; Thu, 05 Jun 2008 15:45:53 -0400 Date: Thu, 05 Jun 2008 19:46:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Patch to limit field name completion candidates Message-ID: <20080605194553.GG25085@caradoc.them.org> Mail-Followup-To: Tom Tromey , gdb-patches@sources.redhat.com References: <20080605170952.GJ29085@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-06/txt/msg00064.txt.bz2 On Thu, Jun 05, 2008 at 01:21:02PM -0600, Tom Tromey wrote: > Daniel> I am concerned that relying on the parser to parse incomplete > Daniel> expressions will not work out. The bodies won't be run until the rule > Daniel> is reduced, and there may not be enough context in what the user has > Daniel> typed to reduce the field completion. I'm not sure that's a real > Daniel> problem, but I worry that it will be fragile. Still - clearly better > Daniel> than nothing. > > I thought about this too, but I couldn't think of a failing case. > > We aren't parsing complete expressions, true, but I think by the time > the COMPLETE token is reduced, we will have reduced the entire LHS of > the struct op expression. And, we throw away the rest of the > expression -- all the malformed parts. > > So, I think it ought to be safe in all cases. Safe, yes. That's not the failure mode I was worried about. I'm wondering if we will ever error out before we reduce the COMPLETE. But it seems to work so far. > Daniel> Oh, and at least a NEWS entry would be good - and probably a > Daniel> manual change too. > > I added a NEWS entry. I am not sure where in the manual to add > anything though. FWIW I didn't do this originally since it seems more > like a QoI thing than a feature requiring documentation. Yes, I understand - but at the same time, the more of our QoI we crow about, the more users will take advantage of it, and the cooler they'll think GDB is. If it was worth implementing, it's also worth documenting. Another example near the bottom of Command Completion would probably do it. The patch and test are OK! Work out the NEWS and manual bits with Eli, and you're home free. -- Daniel Jacobowitz CodeSourcery