RE: MI error msgs and localization

Bjarke Viksoe
2006-02-14T17:40:29Z

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