[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 9 Mar 2006 10:23:30 +1300
> > 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).
- gdb-ui, Nick Roberts, 2006/03/08