RE: MI error msgs and localization

["Bjarke Viksoe" <bviksoe at hotmail dot com>]

>  > the front-end as a "dumb automated shell" and into thinking "integrated
>  > environment with user friendly error messages". Preferrably these 
> messages
>  > should have been streamed out as a MI result-records.
>
> 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?

> 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.

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?

My initial warning was that without "cleaning" the code and making sure 
*all* spurious messages are classified and wrapped in proper MI records, 
localizing may break some tools or see important features disappear because 
they were using the raw console output in lack of proper MI structure 
wrapping.

regards, bjarke viksoe
80386.NET - http://www.viksoe.dk/code/asmil.htm