From: Bob Rossi <bob@brasko.net>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
Subject: Re: Queries in MI
Date: Thu, 07 Jul 2005 01:34:00 -0000 [thread overview]
Message-ID: <20050707013445.GB18932@white> (raw)
In-Reply-To: <17100.30869.182054.443090@farnswood.snap.net.nz>
On Thu, Jul 07, 2005 at 12:34:29PM +1200, Nick Roberts wrote:
> > > If MI becomes properly asynchronous then I'm not sure how to do it.
> > > Perhaps the the frontend could prepend a token on the input, just as MI
> > > already uses tokens for output.
> >
> > Is it possible that FE's would want to automate the response to a query?
> > If so, does it make sense to put the query in the MI protocol?
> >
> > For instance, a FE could implement a way to allow users to set a
> > breakpoint in the source window by class name/function. Then, when the
> > FE tries to automate the command, GDB could respond with a query,
> > the FE could present the user with choices (in dialog) and then send the
> > response back.
> >
> > With the current response, the FE has no way of doing this.
>
> I'm not sure what you're suggesting, but Emacs will always want to allow CLI
> input through the GUD buffer which, for example, will be forwarded to GDB as:
>
> -interpreter-exec console "b asdf"
Of course. Your stating the case when the user sends a command to GDB
and get's a query as a response. That's fine.
What about the case when the FE sends a command to GDB and has to deal
with the query? That isn't capable with the current output. The MI
response would have to have the query information built into it, like,
-break-insert "b asdf"
^done,query={choice1="...",choice2="..."}
FE sends->choice1
...
I currently don't have a need for such a feature, but I'm just
suggesting that the current mechanism doesn't allow the FE to do this
sort of thing nicely. I'm sure it will be needed eventually.
Bob Rossi
next prev parent reply other threads:[~2005-07-07 1:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-06 12:31 MI usage inside a user-defined commands Karganov Konstantin
2005-07-06 13:14 ` Daniel Jacobowitz
2005-07-06 13:46 ` Karganov Konstantin
2005-07-06 13:50 ` Daniel Jacobowitz
2005-07-06 13:57 ` Karganov Konstantin
2005-07-07 12:21 ` Karganov Konstantin
2005-07-07 13:03 ` Daniel Jacobowitz
2005-07-07 14:16 ` Karganov Konstantin
2005-07-07 21:47 ` Nick Roberts
2005-07-06 21:26 ` Nick Roberts
2005-07-06 21:28 ` Daniel Jacobowitz
2005-07-06 22:50 ` Queries in MI [was Re: MI usage inside a user-defined commands] Nick Roberts
2005-07-06 23:06 ` Daniel Jacobowitz
2005-07-06 23:46 ` Bob Rossi
2005-07-07 0:33 ` Queries in MI Nick Roberts
2005-07-07 1:34 ` Bob Rossi [this message]
2005-07-07 3:32 ` Nick Roberts
2005-07-06 21:41 ` MI usage inside a user-defined commands Bob Rossi
[not found] <1120724185.29158.ezmlm@sources.redhat.com>
2005-07-07 18:10 ` Queries in MI Jim Ingham
2005-07-08 16:37 Alain Magloire
2005-07-08 17:39 ` Jim Ingham
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=20050707013445.GB18932@white \
--to=bob@brasko.net \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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