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

[Vladimir Prus <vladimir@codesourcery.com>]

Nick Roberts wrote:

>  > > Isn't every arg a local? Why would an IDE want to display arguments
>  > > and locals differently?
>  > > In KDevelop I added the arguments to the locals.
>  > > -stack-list-locals-and-args would be perfect.
>  > 
>  > [Qt Creator does the same btw] So for me, too, yes.
>  > 
>  > But in any case it would be nice to be as open as (easily) possible
>  > to other approaches and not to force some design decision on a
>  > frontend. In case of  -stack-list-locals-and-args  that would be
>  > possible by e.g. adding a  kind="arg" / kind="local" flag or such.
>  > 
>  > On a related note, can't we have the contents of a
>  > '-stack-list-locals-and-args' in the *stopped  message?
>  > 
>  > _That_ would save a roundtrip, -stack-list-locals-and-args would
>  > probably not save time at all, at best remove twenty lines of
>  > frontend code...
> 
> If "added the arguments to the locals" means combining the output of
> -stack-list-arguments with -stack-list-locals then presumably
> -stack-list-locals-and-args would save one round trip time.  I don't think the
> extra would be very expensive though.
> 
> Another, possibly bigger, benefit of introducing such new commands is that the
> syntax could be more formally defined and they could gradually replace old
> ones.
> 
> Currently the output syntax is:
> 
> `TUPLE ==>'
>      ` "{}" | "{" RESULT ( "," RESULT )* "}" '
> 
> `LIST ==>'
>      ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )*
>      "]" '
> 
> and it would be nice to have:
> 
> 
> `TUPLE ==>'
>      ` "{}" | "{" RESULT ( "," RESULT )* "}" '
> 
> `LIST ==>'
>      ` "[]" | "[" VALUE ( "," VALUE )* "]" '
> 
> 
> -stack-list-locals is one of the commands that has
> 
> "[" RESULT ( "," RESULT )* "]"  output.
> 
> 
> One reason why, in Emacs, we don't fully parse MI output, but use regular
> expression matching, is because of these inconsistencies.

Can you clarify this? KDevelop does use a parser and convert MI into
a convenient internal representation, so it is clearly possible in C++.
I don't know much about Emacs internals -- is there some problem with
parsing methods available there?

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

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

- Volodya