Re: [PATCH] MI error messages

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

Eli Zaretskii writes:
 > > 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 don't care much, but isn't mi-common.c a better place?

mi-common.c seems a bit of a misnomer.  Perhap common here means frequent
rather than shared.  mi-common.h isn't included in any of the c files apart
from mi-common.c

 > > I think it would be better to call it something like mi_usage_error
 > 
 > I have no problem with mi_usage_error.
 > 
 > > 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.
 > 
 > Yes.  And that is why they should go through `error', not through
 > `mi_usage_error'.

I presumed mi_usage_error would call error.  That way the error is caught and
any cleanups and rewinds are done.  However, you are right, it would be nicer
just to get:

(gdb) 
-stack-select-frame
Usage: FRAME_SPEC.
(gdb) 

instead of

(gdb) 
-stack-select-frame
&"Usage: -stack-select-frame FRAME_SPEC\n"
^error,msg="Usage: -stack-select-frame FRAME_SPEC"
(gdb) 

as these errors aren't intended for the user when the frontend is being used.

 > > Perhaps they should be made more transparent.
 > 
 > I guess you mean ``more self-explanatory''.  Yes, I agree.  One way of
 > doing that is not to hide relevant context information that is
 > available at the locus of the error message; in this case, that
 > context is the name of the object.  Thus,
 > 
 > 	Variable object `warranty' not found.
 > 
 > is IMHO much better, even though your suggestion is an additional
 > improvement.

I'll look at submitting a revised patch for mi-cmd-stack.c and mi-cmd-var.c

Nick