gdb-ui

gdb-ui

[Nick Roberts]

I'm aware gdb-ui can get into a confused state because Emacs has no way of
knowing if input is going to gdb or the program being debugged. The code on
which it is based (gdba.el) avoided the problem by always using a separate
buffer for program input.

The problem occurs with gdb-send which sends input immediately if execution
hasn't stopped:

(defun gdb-send (proc string)
  "A comint send filter for gdb.
This filter may simply queue input for a later time."
  (with-current-buffer gud-comint-buffer
    (let ((inhibit-read-only t))
      (remove-text-properties (point-min) (point-max) '(face))))
  (let ((item (concat string "\n")))
    (if gud-running
        ^^^^^^^^^^^
      (progn
	(if gdb-enable-debug (push (cons 'send item) gdb-debug-ring))
	(process-send-string proc item))
      (gdb-enqueue-input item))))


I attach a patch that deals with this problem by making the user decide if
input is for GDB or the inferior (<return> queues the input (for GDB),
<C-return> sends it immediately (for the program being debugged)).  Its not
attractive but I think it is necessary if the GUD buffer is used for input to
both.

Does anybody use gdb-ui and encounter this problem?  If so, do you consider
that this problem justifies such a change?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** /home/nickrob/emacs/lisp/progmodes/gdb-ui.el	2006-03-07 23:17:32.000000000 +1300
--- /home/nickrob/emacs/lisp/progmodes/mygdb-ui.el	2006-03-08 19:04:12.605909128 +1300
*************** With arg, use separate IO iff arg is pos
*** 439,444 ****
--- 439,445 ----
  			(gdb-find-watch-expression) "%e")) arg)
  	   nil   "Print the emacs s-expression.")
  
+   (define-key gud-mode-map [C-return] 'gdb-input)
    (define-key gud-minor-mode-map [left-margin mouse-1]
      'gdb-mouse-set-clear-breakpoint)
    (define-key gud-minor-mode-map [left-fringe mouse-1]
*************** With arg, use separate IO iff arg is pos
*** 464,470 ****
    (define-key gud-minor-mode-map [left-fringe mouse-3]
      'gdb-mouse-toggle-breakpoint-fringe)
  
!   (setq comint-input-sender 'gdb-send)
  
    ;; (re-)initialize
    (setq gdb-frame-address (if gdb-show-main "main" nil))
--- 465,471 ----
    (define-key gud-minor-mode-map [left-fringe mouse-3]
      'gdb-mouse-toggle-breakpoint-fringe)
  
!   (setq comint-input-sender 'gdb-send-gdb)
  
    ;; (re-)initialize
    (setq gdb-frame-address (if gdb-show-main "main" nil))
*************** The key should be one of the cars in `gd
*** 1020,1038 ****
  ;; These lists are consumed tail first.
  ;;
  
! (defun gdb-send (proc string)
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (with-current-buffer gud-comint-buffer
      (let ((inhibit-read-only t))
        (remove-text-properties (point-min) (point-max) '(face))))
    (let ((item (concat string "\n")))
!     (if gud-running
!       (progn
! 	(if gdb-enable-debug (push (cons 'send item) gdb-debug-ring))
! 	(process-send-string proc item))
        (gdb-enqueue-input item))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
  
--- 1021,1053 ----
  ;; These lists are consumed tail first.
  ;;
  
! (defun gdb-send-gdb (proc string)
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (with-current-buffer gud-comint-buffer
      (let ((inhibit-read-only t))
        (remove-text-properties (point-min) (point-max) '(face))))
    (let ((item (concat string "\n")))
!     (progn
!       (if gdb-enable-debug (push (cons 'send-item item) gdb-debug-ring))
        (gdb-enqueue-input item))))
  
+ (defun gdb-send-inferior (proc string)
+   "A comint send filter for gdb.
+ This filter sends input immediately."
+   (with-current-buffer gud-comint-buffer
+     (let ((inhibit-read-only t))
+       (remove-text-properties (point-min) (point-max) '(face))))
+   (let ((item (concat string "\n")))
+     (if gdb-enable-debug (push (cons 'send item) gdb-debug-ring))
+     (process-send-string proc item)))
+ 
+ (defun gdb-input ()
+   "Send input to program being debugged."
+   (interactive)
+   (let ((comint-input-sender 'gdb-send-inferior))
+     (comint-send-input)))
+ 
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
  

Diff finished.  Wed Mar  8 19:04:19 2006

Re: gdb-ui

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> I attach a patch that deals with this problem by making the user decide if
> input is for GDB or the inferior (<return> queues the input (for GDB),
> <C-return> sends it immediately (for the program being debugged)).  Its not
> attractive but I think it is necessary if the GUD buffer is used for input to
> both.

But how does a user know whether to hit RET or C-M-RET at any
given moment?  If he made the wrong choice, isn't it too late to
correct it anyway?

In any case:  Please don't use C-return ... 
CUA-mode binds C-return globally to toggle rectangle marking.

C-M-return would be ok...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui

[Markus Gritsch]

Kim F. Storm wrote:
> 
> In any case:  Please don't use C-return ... 
> CUA-mode binds C-return globally to toggle rectangle marking.

So this change in CUA key binding happened recently.  What was wrong 
with the former CUA Shift-return binding for toggle rectangle marking? I 
use C-return to complete words by binding it to dabbrev-expand in my Emacs.

Kind regards,
Markus

Re: gdb-ui

[Kim F. Storm]

Markus Gritsch <gritsch@iue.tuwien.ac.at> writes:

> Kim F. Storm wrote:
>> In any case:  Please don't use C-return ... CUA-mode binds C-return
>> globally to toggle rectangle marking.
>
> So this change in CUA key binding happened recently.  

2005-05-17  Kim F. Storm  <storm@cua.dk>

	* emulation/cua-base.el (cua-use-hyper-key): Doc fix.
	(cua--init-keymaps): Bind C-return instead of S-return to set
	rectangle mark.

	* emulation/cua-rect.el (cua--init-rectangles): Bind C-return
	instead of S-return to toggle/clear rectangle mark.

.. so I wouldn't say "recently".

>                                                       What was wrong
> with the former CUA Shift-return binding for toggle rectangle marking?

Two reasons:

To align it with C-SPC which toggles the region mark.

Typing RET after entering an upper-case word would often resulted in
hitting S-RET with pretty confusing results (huh, no newline? - and then
you have to enter another S-RET to get back to normal editing state once
you realize what really happened).  Must have done that 1000 times myself!

> I use C-return to complete words by binding it to dabbrev-expand in my
> Emacs.


Nothing prevents you from making your own bindings...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdb-ui

[Nick Roberts]

 > > I attach a patch that deals with this problem by making the user decide
 > > if input is for GDB or the inferior (<return> queues the input (for GDB),
 > > <C-return> sends it immediately (for the program being debugged)).  Its
 > > not attractive but I think it is necessary if the GUD buffer is used for
 > > input to both.
 > 
 > But how does a user know whether to hit RET or C-M-RET at any
 > given moment?

If the program is expecting input it normally prompts the user with output e.g

  Enter number of iterations:

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.

 >  If he made the wrong choice, isn't it too late to correct it anyway?

It depends on what he typed and whether he pressed RET or C-M-RET by mistake.
Currently if a user enters input while the program is still running, gdb-ui
tries to recover with gdb-resync.

 > In any case:  Please don't use C-return ... 
 > CUA-mode binds C-return globally to toggle rectangle marking.
 > 
 > C-M-return would be ok...

C-return and C-M-return don't seem to be available on a terminal anyway.
Could I just use M-return?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > I attach a patch that deals with this problem by making the user decide
>  > > if input is for GDB or the inferior (<return> queues the input (for GDB),
>  > > <C-return> sends it immediately (for the program being debugged)).  Its
>  > > not attractive but I think it is necessary if the GUD buffer is used for
>  > > input to both.
>  > 
>  > But how does a user know whether to hit RET or C-M-RET at any
>  > given moment?
>
> If the program is expecting input it normally prompts the user with output e.g
>
>   Enter number of iterations:
>
> 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?) so how does the user
know when gdb-ui _is_ confused so he should use M-return?

>
>  > In any case:  Please don't use C-return ... 
>  > CUA-mode binds C-return globally to toggle rectangle marking.
>  > 
>  > C-M-return would be ok...
>
> 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.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

Re: gdb-ui

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

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

True.  Other modes also bind M-return for their own purposes, so I guess
you can safely use M-return in *gud* buffers.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk