Re: MI error msgs and localization

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 15, 2006 at 12:25:16PM +1300, Nick Roberts wrote:
>  > 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.

You've answered your own question.  The calls which need to be changed
could be changed to call something other than error() itself.  I'm not
sure why you object to a second string argument and don't object to
adding a number to all of those call sites.

The user wouldn't have to remember them, of course - but _I_ would, as
a GDB developer.  Keeping track of all the used numbers in the GDB
source code, et cetera.

-- 
Daniel Jacobowitz
CodeSourcery