RE: MI error msgs and localization

[Nick Roberts <nickrob@snap.net.nz>]

 > >I would guess that most of time GDB is used from the command line where
 > >there is simply no front-end, dumb or otherwise.
 > 
 > But we are talking about MI mode now and how that should be shaped?

Perhaps we are not communicating but you seemed to be suggesting that the
front-end should do any localisation.  I was just saying that GDB has to
do it because it is often run from the command line.

Also you didn't respond to Eli's suggestion to arrange for your front end to
push LC_MESSAGES=C into the environment when it runs GDB.

 > >The error message "Unrecognized option" is not intended to provide 
 > >information
 > >about the GDB version.  If you want to use it for that purpose, thats your
 > >choice, but you can hardly expect the GDB community to "support" that 
 > >feature.
 > 
 > I don't get your point. A front-end can decide how it wants to interpret an 
 > error message as it pleases. I do it because this is the error I get when 
 > -i=mi is used on a version that does not support it at all. It makes sense 
 > in that context since I'm building the command line.

Quite apart from localisation, at some stage it might also make sense to
someone, to change the message to "Unsupported option".  I don't think you can
rely on these messages to be cast in stone.

 > I don't particular like to hard-code these strings. The list of messages I 
 > gave previously are all marked as console-stream-output. What I am saying is 
 > that localizing such error messages will hurt MI dependant tools since the 
 > messages are highly useful for the front-end. I'm not sure what purpose 
 > console-output really has in a Machine Interface as it tends to make sense 
 > only to humans - but I guess some systems are making use of them.
 > 
 > What I'd really like is to see them also wrapped in result-records (sample; 
 > ignore syntax):
 > 
 > ^failed,type="init-option-unrecognized",msg="Unrecognized option"
 > 
 > Does that make any sense?

We've already got ^error as a result field so it doesn't make any sense to me,
 and if "Unrecognized option" comes from the console stream then I think that
 can still change.  The problem seems to be that of handling CLI error output
 in MI.  I see that the standard GNU error function provides for an error
 number which is less likely to change:

 -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
          ...)

I wonder if GDB's error function could have one for MI e.g

&"Unrecognized option\n"
^error,msg="Unrecognized option",code="35"

or even

&"Unrecognized option\n"
^error,code="35"

 instead of just:

&"Unrecognized option\n"
^error,msg="Unrecognized option"

Nick


Nick