Re: [mi] -stack-list-arguments --simple-values

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Replying to an old-ish note.

Nick> People often lament the poor syntax of MI but it really needs a
Nick> plan to replace it with something better.  However, such a plan
Nick> would really need a maintainer to lead it and doesn't really work
Nick> on a Write After Approval basis.

I think we can differentiate here between a plan and the patches
implementing the plan.

In my view we could discuss the plan on the gdb list and reach some kind
of agreement.  This can be initiated by anybody.  If you want to start
it, I will try to help ensure that the discussion reaches some
conclusion.

I think if there is general agreement about the direction then patch
review need not be a big problem.  I suppose my view is based on the
idea that the plan is probably where most of the contention lies, and
usually the implementation bits are straightforward.

Volodya> FWIW, both the above issue is universally believed to be not
Volodya> good, so patches to introduce MI3 version and switch select
Volodya> commands to "right" syntax appear to be fairly simple.

Nick> I quite like the idea of incrementally changing the output with
Nick> new commands because as soon as MI3 is released, you can be sure
Nick> people will find shortcomings with that.  You could say it is a
Nick> more agile approach.

What do you suggest?

I ask because this does seem to come up over and over.  Not only are
there MI formatting bugs, there are things like the recently discussed
"info shared" output problem -- a command that has no MI equivalent, no
use of ui_out, and which, presumably, existing MI consumers handle by
parsing the CLI output.

I have been thinking about this case for a few days and I really don't
have any good solution.  I also think that MI versioning seems to work
at too coarse a granularity.  For pretty-printing we're adding an
explicit "enable" command to work around this problem -- but it seems
odd to have an MI session start off with 100 -enable-foo commands.  And,
this case doesn't account for the mess that it would leave behind if we,
e.g., applied it to the "info shared" case.

Tom