From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1149 invoked by alias); 15 Feb 2006 01:48:07 -0000 Received: (qmail 1140 invoked by uid 22791); 15 Feb 2006 01:48:06 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Feb 2006 01:48:04 +0000 Received: from kahikatea.snap.net.nz (p202-124-114-130.snap.net.nz [202.124.114.130]) by viper.snap.net.nz (Postfix) with ESMTP id D6C807460BB; Wed, 15 Feb 2006 14:47:56 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 1F3AB8890; Wed, 15 Feb 2006 14:46:54 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17394.34829.877266.50785@kahikatea.snap.net.nz> Date: Wed, 15 Feb 2006 01:48:00 -0000 To: Daniel Jacobowitz Cc: Bjarke Viksoe , gdb@sourceware.org Subject: Re: MI error msgs and localization In-Reply-To: <20060214233209.GA5046@nevyn.them.org> References: <17393.12925.270558.512941@kahikatea.snap.net.nz> <17394.17519.510199.853654@kahikatea.snap.net.nz> <20060214210505.GA817@nevyn.them.org> <17394.26332.314215.498261@kahikatea.snap.net.nz> <20060214233209.GA5046@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00149.txt.bz2 > > You wouldn't have to remember them, thay're for use by the front-end, not > > the user. In any case the console log stream gets printed alongside, > > which should be self-explanatory. How would you arrange for the type > > message to be printed? Would you give error a second string argument? > > It has over 1200 calls. > > > > > We have to be careful what error messages get identifiers, though. > > > Please don't anybody go through the source indiscriminately adding > > > them. Many errors will still be subject to change even if you tack > > > permanent identifiers on them. > > > > All calls to error could be given a dummy argument (0, if numbers are > > used), and replaced with a real one only in thoses cases when a need > > arises. > > You've answered your own question. The calls which need to be changed > could be changed to call something other than error() itself. That's not quite what I said but it's a better idea as fewer changes need be made. Better still might be to use a global variable, perhaps mi_error_message in mi-main.c could be used. How about something like the patch below (in mi_execute_command) to be used like this: mi_error_message = xstrprintf ("no-debugging-symbols"); error(_("No debugging symbols found"); to give: &"No debugging symbols found\n" ^error,msg="no-debugging-symbols" I've not used the previous example ("Unrecognized option"), as it comes from getopt_long_only and not error (however, I think all of Bjarke's other examples were from error). WDYT? Nick *** mi-main.c 30 Jan 2006 09:17:56 +1300 1.83 --- mi-main.c 15 Feb 2006 14:31:38 +1300 *************** *** 1171,1177 **** somewhere. */ fputs_unfiltered (command->token, raw_stdout); fputs_unfiltered ("^error,msg=\"", raw_stdout); ! fputstr_unfiltered (result.message, '"', raw_stdout); fputs_unfiltered ("\"\n", raw_stdout); mi_out_rewind (uiout); } --- 1171,1183 ---- somewhere. */ fputs_unfiltered (command->token, raw_stdout); fputs_unfiltered ("^error,msg=\"", raw_stdout); ! if (mi_error_message) ! { ! fputstr_unfiltered (mi_error_message, '"', raw_stdout); ! xfree (mi_error_message); ! } ! else ! fputstr_unfiltered (result.message, '"', raw_stdout); fputs_unfiltered ("\"\n", raw_stdout); mi_out_rewind (uiout); }