From xemacs-m  Tue Dec 31 17:45:54 1996
Received: from alphatech.com (erebus.alphatech.com [198.112.236.2])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id RAA24646 for <xemacs-beta@xemacs.org>; Tue, 31 Dec 1996 17:45:51 -0600 (CST)
Received: from venus.alphatech.com by alphatech.com (4.1/SMI-4.1)
	id AA13625; Tue, 31 Dec 96 18:41:55 EST
Received: from euler.alphatech.com by venus.alphatech.com (4.1/SMI-4.1)
	id AB27421; Tue, 31 Dec 96 18:48:44 EST
Received: by euler.alphatech.com (5.x/SMI-SVR4)
	id AA00485; Tue, 31 Dec 1996 18:40:59 -0500
Date: Tue, 31 Dec 1996 18:40:59 -0500
Message-Id: <9612312340.AA00485@euler.alphatech.com>
From: greg@alphatech.com (Greg Klanderman)
To: xemacs-beta@xemacs.org (XEmacs beta list)
Subject: more gdb woes
Reply-To: greg@alphatech.com


Also in gdb mode in 19.15b4, C-c C-c does not interrupt the process.
The pulldown menu Comint2 -> Send INT does work, even though the menu
says the binding is C-c C-c.

The pulldown menu is running comint-interrupt-subjob (this works)
C-c C-c is running gdb-control-c-subjob (doesn't work).

Strangely, both "C-h w comint-interrupt-subjob" and
"C-h w gdb-control-c-subjob" give C-c C-c.

I'm wondering if I should use GUD, but in gud.el I see,

> ;;; XEmacs: don't autoload this yet since it's still buggy - use the
> ;;; one in gdb.el instead
> (defun gdb (command-line)

Greg

