From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24039 invoked by alias); 21 Jun 2005 09:40:26 -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 24023 invoked by uid 22791); 21 Jun 2005 09:40:19 -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 09:40:19 +0000 Received: from farnswood.snap.net.nz (p169-tnt1.snap.net.nz [202.124.110.169]) by viper.snap.net.nz (Postfix) with ESMTP id C848E5545B3; Tue, 21 Jun 2005 21:40:15 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id E76D162A99; Tue, 21 Jun 2005 10:40:38 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17079.57494.321274.96102@farnswood.snap.net.nz> Date: Tue, 21 Jun 2005 09:40: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> X-SW-Source: 2005-06/txt/msg00331.txt.bz2 > Andreas suggested one way to do this. But I think it would be better > to add a function called, say, mi_error, that would do > > error (_("Usage: %s."), msg); > > where `msg' is a char * string passed as its argument, and then > replace each call to `error' with a call to `mi_error', like so: > > mi_error ("-stack-list-locals PRINT_VALUES"); > > The advantage of this is that "Usage: %s" is not repeated dozens of > times in the message catalog and in the program. 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 think it would be better to call it something like mi_usage_error, as 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. Perhaps they should be made more transparent. For example, if I inadvertantly selected the word warranty before clicking on the tool bar to create a watch expression. The frontend would send: -var-create - * warranty GDB would reply: &"mi_cmd_var_create: unable to create variable object\n" ^error,msg="mi_cmd_var_create: unable to create variable object" which the frontend could parse, but a more helpful message would be: "No symbol warranty in current context." > > Also, in mi-cmd-stack.c, I've given get_selected_frame the message string > > "No stack." but presumably this also gets translated so should it be: > > > > get_selected_frame (_("No stack.")) ? > > Yes. OK > > Some error messages are terminated with a period, others aren't. I don't > > know which style is preferred but clearly it would be best to just use > > one. > > They should all end with a period, I think. OK Nick