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

[Vladimir Prus <vladimir at codesourcery dot com>]

Tom Tromey wrote:

>>>>>> "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.

I presume one approach is to declare MI3 "volatile" and subject to breaking
change on short notice, so that I can evolve and stabilize freely, and
only then be freezed.

- Volodya