From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10071 invoked by alias); 14 Feb 2006 23:26:29 -0000 Received: (qmail 10061 invoked by uid 22791); 14 Feb 2006 23:26:28 -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; Tue, 14 Feb 2006 23:26:23 +0000 Received: from kahikatea.snap.net.nz (p202-124-115-240.snap.net.nz [202.124.115.240]) by viper.snap.net.nz (Postfix) with ESMTP id 5EEFF741058; Wed, 15 Feb 2006 12:26:18 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 1617E8890; Wed, 15 Feb 2006 12:25:17 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17394.26332.314215.498261@kahikatea.snap.net.nz> Date: Tue, 14 Feb 2006 23:26:00 -0000 To: Daniel Jacobowitz Cc: Bjarke Viksoe , gdb@sourceware.org Subject: Re: MI error msgs and localization In-Reply-To: <20060214210505.GA817@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> 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/msg00147.txt.bz2 > GCC developers spent a lot of time talking about this. I think the > trick to doing this right is actually to do it the way Bjarke > suggested: msg= as a free-form, explanatory text, and type= (or code=, > or something else) as a documented identifier. But using numbers for > the identifiers is not necessarily a good idea, because keeping track > of them is error-prone. I'd suggest that > type="init-option-unrecognized" was a lot more memorable than > "code=35". 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. Nick