Re: MI error msgs and localization

Daniel Jacobowitz
2006-02-13T20:01:54Z

Just to add to what others have said...

On Mon, Feb 13, 2006 at 07:37:10PM +0100, Bjarke Viksoe wrote:
> >These messages appear to be part of the CLI output intended for the user
> >and
> >not MI. It seems natural to translate them.
>
> I really don't agree at all. Very few output in MI mode is/should be
> intended for users only. You have got get past the stage where you think of
> 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 translate "No symbol table loaded..." into asking the user to switch to
> debug-mode in my tool. "Unrecognized option" pop ups that the GDB version
> is too old, reinstall needed. "Thread x has terminated" refreshed the
> thread list etc etc etc. No user behind a front-end will understand "No
> such process." or "No executable file specified" by itself when the cause
> of this is some magic done by the controlling front-end.

This is a clever thing to do. However, like most clever things, expect
to have to do some legwork to keep it working.

The error messages are deliberately not part of the documented
interface. The documented interface we take pains to keep compatible;
the undocumented bits are subject to change at any time. If there are
particular messages that are valuable to front ends, then maybe they
should get their own documentation and MI representation; don't count
on the magic strings in ^error to remain unchanged.

> >As stated in the manual, MI is still evolving. The best way to make it do
> >the things you want is to participate in its development.
> >
>
> Unfortunately I see this reply too often here.

That's your invitation to help. There's plenty of ways to help without
coding on GDB - the documentation, or simply participating when
developers ask questions about how people are really using MI.

But without more people interested in doing MI development, it WILL NOT
improve. Many of us have got enough GDB issues we want to fix without
volunteering to improve MI also; we need people who care about it.

--
Daniel Jacobowitz
CodeSourcery