Re: [PATCH] MI error messages

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

 > Andreas suggested one way to do this.  But I think it would be better
 > to add a function called, say, mi_error, that would do
 > 
 >       error (_("Usage: %s."), msg);
 > 
 > where `msg' is a char * string passed as its argument, and then
 > replace each call to `error' with a call to `mi_error', like so:
 > 
 >       mi_error ("-stack-list-locals PRINT_VALUES");
 > 
 > The advantage of this is that "Usage: %s" is not repeated dozens of
 > times in the message catalog and in the program.

Which file should mi_error/mi_usage_error go in?  mi-cmds.c seems the best
option to me as the mi-cmd-*.c files include mi-cmds.h.

I think it would be better to call it something like mi_usage_error, as there
are many other errors generated in MI e.g.

    error (_("mi_cmd_var_delete: Variable object not found."));

which, I guess should just be:

    error (_("Variable object not found."));

However, unlike the usage error messages which should only be seen by the
person writing the frontend, these messages _will_ be seen by the user.
Perhaps they should be made more transparent.  For example, if I inadvertantly
selected the word warranty before clicking on the tool bar to create a watch
expression.  The frontend would send:

-var-create - * warranty

GDB would reply:

&"mi_cmd_var_create: unable to create variable object\n"
^error,msg="mi_cmd_var_create: unable to create variable object"

which the frontend could parse, but a more helpful message would be:

"No symbol warranty in current context."

 > > Also, in mi-cmd-stack.c, I've given get_selected_frame the message string
 > > "No stack." but presumably this also gets translated so should it be:
 > > 
 > >     get_selected_frame (_("No stack.")) ?
 > 
 > Yes.

OK

 > > Some error messages are terminated with a period, others aren't.  I don't
 > > know which style is preferred but clearly it would be best to just use
 > > one.
 > 
 > They should all end with a period, I think.

OK

Nick