From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27484 invoked by alias); 21 Jun 2005 19:51:25 -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 27463 invoked by uid 22791); 21 Jun 2005 19:51:21 -0000 Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 21 Jun 2005 19:51:21 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-250-33.inter.net.il [84.228.250.33]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id BPK11086 (AUTH halo1); Tue, 21 Jun 2005 22:51:12 +0300 (IDT) Date: Tue, 21 Jun 2005 19:51:00 -0000 Message-Id: From: Eli Zaretskii To: Nick Roberts CC: gdb-patches@sources.redhat.com In-reply-to: <17079.57494.321274.96102@farnswood.snap.net.nz> (message from Nick Roberts on Tue, 21 Jun 2005 21:40:38 +1200) Subject: Re: [PATCH] MI error messages Reply-to: Eli Zaretskii 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/msg00336.txt.bz2 > From: Nick Roberts > Date: Tue, 21 Jun 2005 21:40:38 +1200 > Cc: gdb-patches@sources.redhat.com > > 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? > 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'. > 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.