This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]