From: nickrob@snap.net.nz (Nick Roberts)
To: "André Pönitz" <andre.poenitz@nokia.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [mi] -stack-list-arguments --simple-values
Date: Thu, 02 Jul 2009 09:37:00 -0000 [thread overview]
Message-ID: <19020.32725.55167.391078@totara.tehura.co.nz> (raw)
In-Reply-To: <200907021005.48239.andre.poenitz@nokia.com>
> > 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.
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.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2009-07-02 9:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-30 9:39 Vladimir Prus
2009-06-30 13:59 ` Daniel Jacobowitz
2009-07-01 13:13 ` Nick Roberts
2009-07-01 17:34 ` Vladimir Prus
2009-07-01 17:45 ` Niko Sams
2009-07-02 8:05 ` André Pönitz
2009-07-02 8:13 ` Niko Sams
2009-07-02 9:37 ` Nick Roberts [this message]
2009-07-02 10:30 ` Vladimir Prus
2009-07-03 8:33 ` Nick Roberts
2009-07-24 22:07 ` Tom Tromey
2009-07-25 7:21 ` Vladimir Prus
2009-07-26 11:42 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19020.32725.55167.391078@totara.tehura.co.nz \
--to=nickrob@snap.net.nz \
--cc=andre.poenitz@nokia.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox