From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9512 invoked by alias); 21 Feb 2005 02:36:18 -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 9458 invoked from network); 21 Feb 2005 02:36:14 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 21 Feb 2005 02:36:14 -0000 Received: from farnswood.snap.net.nz (p77-tnt2.snap.net.nz [202.124.108.77]) by viper.snap.net.nz (Postfix) with ESMTP id F107F40F2AC; Mon, 21 Feb 2005 15:36:11 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 4083B62FBE; Mon, 21 Feb 2005 02:34:44 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16921.18627.457594.938060@farnswood.snap.net.nz> Date: Mon, 21 Feb 2005 04:33:00 -0000 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH: gdb/mi + doco] -var-update In-Reply-To: <01c51709$Blat.v2.4$4a3292a0@zahav.net.il> References: <16919.7660.144228.334687@farnswood.snap.net.nz> <01c5167f$Blat.v2.4$9a7a6f60@zahav.net.il> <16919.53411.753668.336933@farnswood.snap.net.nz> <01c51709$Blat.v2.4$4a3292a0@zahav.net.il> X-SW-Source: 2005-02/txt/msg00216.txt.bz2 > > I'm not familiar with this device but this line has been cut and pasted > > from mi_cmd_var_list_children and all the other error messages in MI have > > it too. > > If other messages are marked up with _(), then this is okay. But I > still think the const char [] strings should be defined once and used > elsewhere in this function. OK but this only makes sense if it is done consistently. So I offer to do it for all of the MI error messages. I'll submit one example first. > > > This text should refer to @var{print-values} you used inside > > > @smallexample, otherwise it is not clear what should be used in its > > > stead. > > > > I'm not sure what you mean here. > > The usage description used @var{print-values}, which is a variable > parameter, but the text does not refer to @var{print-values}. A > reader will not understand what to put instead of @var{print-values} > if you don't mention it. I think I follow that now. > > > Also, I find the choice of "--all-values" unfortunate. The opposite > > > of "--no-values" is something like "--with-values" or > > > "--print-values", not "--all-values". > > > > If it was a CLI command I would agree but the exact syntax of MI commands > > only has to be referred to by developers and not remembered by users. > > In this case, users==developers. Mnemonic names matter even for > developers of GDB front ends. > > > I've used "--all-values" because, in the case of -var-list-children there > > is a third possibility: "--simple-values" and, to me, it seems simpler to > > have only three values for print_values (mi-cmds.h): > > > > enum print_values { > > PRINT_NO_VALUES, > > PRINT_ALL_VALUES, > > PRINT_SIMPLE_VALUES > > }; > > I see the reason, but I think it is not important enough to use > "--all-values". Anyway, the switch text does not need to be similar > to the enum name, even if you use PRINT_ALL_VALUES in the enum. OK. But again this only makes sense if I change -var-list-children too. This wouldn't be backward compatible but I doubt that anyone is currently relying on it. Is that acceptable? Nick