Re: gdb-ui

[Nick Roberts]

> > If the program has no input, the user doesn't need to do anything new and
 > > the change just helps to prevent gdb-ui getting confused.
 > 
 > But in most cases, gdb-ui is not confused (right?)...

I'm not sure, it all depends on the nature of the program and how rapidly the
user types input.  We've had a related thread before (Oct 2004,
gud breakage: ^done,changelist=[]) when I said: 

Me> When debugging programs which don't read from standard input, such as Emacs
Me> (and Lilypond?) the conditional clause in gdb-send can be removed:
                       (on the value of gud-running)

Me>   (defun gdb-send (proc string)
Me>    "A comint send filter for gdb.
Me>  This filter may simply queue output for a later time."
Me>      (gdb-enqueue-input (concat string "\n")))

Me> This should eliminate the problem for such programs but will eventually
Me> hang for those expecting input.

So if you have patched your local version gdb-ui shouldn't confused, but this
is not a general solution.

 >                                                    ...so how does the user
 > know when gdb-ui _is_ confused so he should use M-return?

Perhaps I've not been clear.  He should type M-return when the program is
prompting for input not when gdb-ui is confused.

 > > C-return and C-M-return don't seem to be available on a terminal anyway.
 > > Could I just use M-return?
 > 
 > What about C-u RET ?  Then we don't need another key.

It's a bit harder to type.  Unlike C-return for CUA-mode, it would only be a
local binding (to the GUD buffer).

Nick