On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
Seems like having a callback in your parser to handle async messages
from gdb represents cleanly what is going on. You haven't gotten a
completed MI command yet, and you're not ready for another MI
command. But gdb is asking on the side for more input. Seems like
making the two cases look the same is more likely to cause trouble.
I undstand, and sort of agree with you. However, things get slightly
worse from my perspective. I've designed my FE thus far to behave like
this:
- It is always looking for data from GDB to assemble MI output
records.
- It will send only a single GDB command at a time.
With that in mind, my FE assembles an MI output record, and then sends
it up the chain to be looked at more specifically. However, with this
callback-in-the-middle scenario, my FE will have to be retrained to
handle partially returned MI output records.
Does this seem acceptable to you?
For instance, the annotate=2 looks like this:
pre-prompt
(gdb)
prompt
b A::func
post-prompt
[0] cancel
[1] all
[2] A::func(float) at overloaded.cpp:8
[3] A::func(int) at overloaded.cpp:7
pre-overload-choice
overload-choice
I think the overload choice is as much a prompt as any other
command. I'm
not exactly sure why you think it's a "special" input from the user.