From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: gdbui hang Date: 11 May 2004 19:23:00 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <16543.48815.692499.486290@nick.uklinux.net> <87fza8qewy.fsf-monnier+emacs@gnu.org> <16545.16531.713274.678978@nick.uklinux.net> <16545.22265.561216.75019@nick.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084324298 12135 80.91.224.253 (12 May 2004 01:11:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 01:11:38 +0000 (UTC) Cc: emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 12 03:11:31 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNiHT-0000OL-00 for ; Wed, 12 May 2004 03:11:31 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNiHS-0001eY-00 for ; Wed, 12 May 2004 03:11:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNi9F-0008Qm-7m for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 21:03:01 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNi8p-0008ND-1O for emacs-devel@gnu.org; Tue, 11 May 2004 21:02:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNi3z-0007Sk-LL for emacs-devel@gnu.org; Tue, 11 May 2004 20:58:07 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BNhzb-0006i0-J0; Tue, 11 May 2004 20:53:04 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by mx20.gnu.org with esmtp (Exim 4.34) id 1BNgeO-0006bW-0Q; Tue, 11 May 2004 19:27:08 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id DC4A8204BE; Tue, 11 May 2004 19:23:00 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id C81C18C6AE; Tue, 11 May 2004 19:23:00 -0400 (EDT) Original-To: Nick Roberts In-Reply-To: <16545.22265.561216.75019@nick.uklinux.net> Original-Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.908, requis 5, BAYES_10 -0.91) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23200 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23200 >> In general I think the add-hook should not be global but only apply to the >> *gud* buffer. > kill-buffer-hook *is* a global variable, though. gud-kill-buffer-hook does > only apply to the *gud* buffer though the condition (eq (current-buffer) > gud-comint-buffer). What's there to make local? Se the `local' arg of ad-hook. >> But I must say that I don't understand at all what the >> current gud-kill-buffer-hook is doing: >> >> % grep -nH gud-minor-mode-type *.el >> gud.el:2504:(defvar gud-minor-mode-type nil) >> gud.el:2512: (if (eq gud-minor-mode-type 'gdba) >> gud.el:2549: (setq gud-minor-mode-type gud-minor-mode))) >> >> It's a variable used in the process sentinel but only set when >> a gud-minor-mode buffer is killed. Sounds pretty odd, yet there's no >> comment explaniing what going on. Sounds like a bug (or some left over >> code). > I wrote that code, a while back. Here's my logic: > gud-sentinel needs to do different things depending on whether gdb is run > with "-fullname" (gud-minor-mode = 'gdb) or "-annotate=3" or > (gud-minor-mode = 'gdba). gud-sentinel is executed after the buffer is > killed and so can't deduce which case it is dealing with. However, > gud-kill-buffer-hook is run before the buffer is killed, so it is used to > store gud-minor-mode in the variable gud-minor-mode-type. Ah I see. [ Reminds me that I'd like to add property lists to processes. ] But in this particular case, I guess the best approach is to merge gdb-reset into gud-reset so the sentinel doesn't have to care about the difference between various gud-minor-mode. BTW: the regexp "^\*.+*$" in gdb-reset should probably be "\\`\\*.+\\*\\'" [ or even thrown away and replaced with something like a buffer-local variable `gud-auxiliary-buffer' which would be set to non-nil (better yet: to the main *gud* buffer) in those *foo* buffers. ] > (defun gud-kill-buffer-hook () > (when (eq (current-buffer) gud-comint-buffer) > (setq gud-minor-mode-type gud-minor-mode) > (condition-case nil > (kill-process (get-buffer-process gud-comint-buffer)) > (error nil)))) Sure. Except I'd add the hook buffer-locally so you don't need to check (eq (current-buffer) gud-comint-buffer). Stefan