From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4926 invoked by alias); 2 Jan 2008 04:35:24 -0000 Received: (qmail 4884 invoked by uid 22791); 2 Jan 2008 04:35:22 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jan 2008 04:34:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DCEC02A966D; Tue, 1 Jan 2008 23:34:57 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G4K3Wq9iZN9W; Tue, 1 Jan 2008 23:34:57 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D86982A966C; Tue, 1 Jan 2008 23:34:56 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id EBFDAE7ACB; Tue, 1 Jan 2008 20:34:49 -0800 (PST) Date: Wed, 02 Jan 2008 04:35:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA] new set/show multiple-choice-auto-select commands Message-ID: <20080102043449.GA15903@adacore.com> References: <20080101143621.GC24843@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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-01/txt/msg00011.txt.bz2 > > This has been a very practical solution when in interactive mode > > (ie when a user is driving the session), but an annoyance when driving > > the debugger with a tool. > > Please explain why, I'm not sure I understand. When driving GDB with > a tool, the tool is responsible for doing TRT, so why is this a > nuisance? And how does your solution alleviates that nuisance? The "tool" in this case was a GDB script, and the customer didn't want to see the menus in the output. And also, some of the AdaCore engineers were tired of seeing the menu when they were always selecting the "all" choice. So it's not a matter of the tool doing TRT. Note that "nuisance" is stronger than what I meant: It's annoying *sometimes* to have to deal with the menu. Each individual has its own preferences, and this option allows you to configure GDB accordingly. > Can you please give an example of the behavior under each one of these > settings? I'm afraid I cannot judge the suggestion without > understanding its effect on the users. Sure. When the setting is "off", the behavior is unchanged, and when the expression has multiple matches, the output will look like this: (gdb) b normal_menu [0] cancel [1] all [2] pck.normal_menu at pck.adb:6 [3] pck.normal_menu at pck.adb:11 > At this point, if you select 0 (cancel): > 0 cancelled (gdb) If you select 1 (all): > 1 Breakpoint 1 at 0x8049517: file pck.adb, line 6. Breakpoint 2 at 0x804951d: file pck.adb, line 11. warning: Multiple breakpoints were set. Use the "delete" command to delete unwanted breakpoints. And if you select either 2 or 3 (one specific location): > 2 Breakpoint 4 at 0x8049517: file pck.adb, line 6. When the setting is "all", then it's the same as the user always selecting "1" (all) everytime the menu is displayed, except that the menu is no longer displayed and all locations are always selected: (gdb) set multiple-choice-auto-select all (gdb) b normal_menu Breakpoint 5 at 0x8049517: file pck.adb, line 6. Breakpoint 6 at 0x804951d: file pck.adb, line 11. warning: Multiple breakpoints were set. Use the "delete" command to delete unwanted breakpoints. And, if the setting is "cancel", it's the same as the user always selecting "0" (cancel) everytime. Similarly, the menu is never displayed, a message is printed explaining that the expression is ambiguous and has been canceled. (gdb) b normal_menu canceled because the command is ambiguous and the multiple-choice menu has been deactivated. See set/show multiple-choice-auto-select. > > + error (_("\ > > +canceled because the command is ambiguous and the multiple-choice menu\n\ > > +has been deactivated. See set/show multiple-choice-auto-select.")); > > Shouldn't "canceled" be capitalized? Yes, you're right. > The first line of the command's doc string should be a complete > sentence, or at least a complete phrase. That's because some help > commands only display the first line (and stop at the first comma or > period in that line, IIRC). We can fix that too. -- Joel