From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19013 invoked by alias); 21 Jun 2005 21:43: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 19000 invoked by uid 22791); 21 Jun 2005 21:43:14 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 21 Jun 2005 21:43:14 +0000 Received: from farnswood.snap.net.nz (p35-tnt2.snap.net.nz [202.124.108.35]) by viper.snap.net.nz (Postfix) with ESMTP id AE02153E8A5; Wed, 22 Jun 2005 09:43:10 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id E737962A99; Tue, 21 Jun 2005 22:44:18 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17080.35377.519988.619664@farnswood.snap.net.nz> Date: Tue, 21 Jun 2005 21:43:00 -0000 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI error messages In-Reply-To: References: <17075.57612.684597.392526@farnswood.snap.net.nz> <20050618155742.GB3663@nevyn.them.org> <17076.42233.730605.834264@farnswood.snap.net.nz> <20050618232032.GA28368@nevyn.them.org> <17076.59646.873454.551250@farnswood.snap.net.nz> <20050619145612.GA8219@nevyn.them.org> <17077.61587.164352.664225@farnswood.snap.net.nz> <17078.19977.660644.9978@farnswood.snap.net.nz> <20050620135108.GA29453@nevyn.them.org> <17079.14386.484824.134375@farnswood.snap.net.nz> <17079.57494.321274.96102@farnswood.snap.net.nz> X-SW-Source: 2005-06/txt/msg00337.txt.bz2 Eli Zaretskii writes: > > Which file should mi_error/mi_usage_error go in? mi-cmds.c seems the best > > option to me as the mi-cmd-*.c files include mi-cmds.h. > > I don't care much, but isn't mi-common.c a better place? mi-common.c seems a bit of a misnomer. Perhap common here means frequent rather than shared. mi-common.h isn't included in any of the c files apart from mi-common.c > > I think it would be better to call it something like mi_usage_error > > I have no problem with mi_usage_error. > > > there are many other errors generated in MI e.g. > > > > error (_("mi_cmd_var_delete: Variable object not found.")); > > > > which, I guess should just be: > > > > error (_("Variable object not found.")); > > > > However, unlike the usage error messages which should only be seen by the > > person writing the frontend, these messages _will_ be seen by the user. > > Yes. And that is why they should go through `error', not through > `mi_usage_error'. I presumed mi_usage_error would call error. That way the error is caught and any cleanups and rewinds are done. However, you are right, it would be nicer just to get: (gdb) -stack-select-frame Usage: FRAME_SPEC. (gdb) instead of (gdb) -stack-select-frame &"Usage: -stack-select-frame FRAME_SPEC\n" ^error,msg="Usage: -stack-select-frame FRAME_SPEC" (gdb) as these errors aren't intended for the user when the frontend is being used. > > Perhaps they should be made more transparent. > > I guess you mean ``more self-explanatory''. Yes, I agree. One way of > doing that is not to hide relevant context information that is > available at the locus of the error message; in this case, that > context is the name of the object. Thus, > > Variable object `warranty' not found. > > is IMHO much better, even though your suggestion is an additional > improvement. I'll look at submitting a revised patch for mi-cmd-stack.c and mi-cmd-var.c Nick