This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] MI error messages
> 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