From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22394 invoked by alias); 13 Jan 2003 21:14:44 -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 22372 invoked from network); 13 Jan 2003 21:14:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 13 Jan 2003 21:14:43 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0DKkHB05058 for ; Mon, 13 Jan 2003 15:46:17 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0DLEOn02994; Mon, 13 Jan 2003 16:14:24 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h0DLENE19173; Mon, 13 Jan 2003 13:14:23 -0800 Message-ID: <3E232C2F.9A5EB7A0@redhat.com> Date: Mon, 13 Jan 2003 21:14:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Elena Zannoni CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] New 'to' command References: <15905.49160.629338.929610@localhost.redhat.com> <20030112194209.GA5996@nevyn.them.org> <15905.56281.661173.8077@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00493.txt.bz2 Elena Zannoni wrote: > > Daniel Jacobowitz writes: > > On Sun, Jan 12, 2003 at 02:20:40PM -0500, Elena Zannoni wrote: > > > > > > Following up from the long long long thread: > > > http://sources.redhat.com/ml/gdb-patches/2002-12/msg00584.html > > > > > > Here is a new command called 'to', which takes a location (any > > > location) specified like for the break command, and simply continues > > > to it, with the restriction that the current frame is not exited. > > > > > > I have left the current 'until' command alone, except for a modification > > > of the help string. > > > > > > If this is agreed upon, I'll submit doco changes and testsuite. > > > > Well, I like it just because it's nice to see us moving forwards... and > > "to" is as good a name as any, I guess. I'm worried that it doesn't > > pass the obviousness test: > > > > - Hypothesize a forgetful Dan. This is easy; I can provide one any > > time you need one. > > - He remembers a long thread about until and to > > - But he's forgotten which one does which! > > - And he didn't think of checking in "help"! > > - So, how does he figure out which does which? > > > > I think that the names of two commands should suggest logically > > different behaviors, or we're just setting up more confusion. I don't > > see how given "until 900" and "to 900" the user could figure out which > > wants the current frame. > > > > I am not attached to either name, I just couldn't come up with better > ones. My main rationale was to leave 'until' untouched. > > > That said, I don't mind this solution. I'll get used to it; I suspect > > anyone else who wants to use it can too. Let's see if you satisfy > > everyone else :) > > > > Let's hope... I have no complaints. Only -- wasn't "until" broken? Is it still broken? Should we make "until" and "to" mutually exclusive, ie. should "until" reject locations outside the current frame?