From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: `q' in debugger with a dedicated *Backtrace* window Date: Sat, 17 Mar 2007 19:42:21 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174185843 22394 80.91.229.12 (18 Mar 2007 02:44:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 18 Mar 2007 02:44:03 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 18 03:44:00 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HSlNH-0003Vg-7c for ged-emacs-devel@m.gmane.org; Sun, 18 Mar 2007 03:43:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HSlOZ-0004ay-Vp for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2007 21:45:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HSlOX-0004aj-2j for emacs-devel@gnu.org; Sat, 17 Mar 2007 22:45:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HSlOU-0004aV-V0 for emacs-devel@gnu.org; Sat, 17 Mar 2007 22:45:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HSlOU-0004aS-Qz for emacs-devel@gnu.org; Sat, 17 Mar 2007 21:45:14 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HSlNC-0003eD-AB for emacs-devel@gnu.org; Sat, 17 Mar 2007 22:43:54 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l2I2hpKr012846 for ; Sat, 17 Mar 2007 20:43:51 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2I1Mxdc017454 for ; Sat, 17 Mar 2007 20:43:51 -0600 Original-Received: from 141.144.73.0 by acsmt351.oracle.com with ESMTP id 2540303361174185751; Sat, 17 Mar 2007 19:42:31 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68040 Archived-At: I use a dedicated window for the debugger: non-nil pop-up-frames and non-nil window-dedicated-p. In Emacs 22, when I use `q' in the debugger, the debugger frame is deleted (disappears). This does not happen in Emacs 20 or 21. To me, this is an annoying bug. Users might well position or resize the debugger frame manually or with custom code. `q' means to quit the debugger, but it doesn't mean to throw away the debugger buffer or frame. The debugger might well be reentered later, and the user might want to reuse the same frame. This appears to be the relevant code (in monster function `debug'). In Emacs 21, the code is simply this, which leaves the *Backtrace* frame empty and available for future use - just what I want: ;; Still visible despite the save-window-excursion? Maybe it ;; it's in a pop-up frame. It would be annoying to delete and ;; recreate it every time the debugger stops, so instead we'll ;; erase it but leave it visible. (save-excursion (set-buffer debugger-buffer) (erase-buffer) (fundamental-mode)) I agree with that comment, BTW: it *is* now annoying that it is deleted and recreated in Emacs 22 - the frame, that is. In Emacs 22, that code has become the following: (with-current-buffer debugger-buffer (erase-buffer) (fundamental-mode) (with-selected-window (get-buffer-window debugger-buffer 0) (when (and (window-dedicated-p (selected-window)) (not debugger-will-be-back)) ;; If the window is not dedicated, burying the buffer ;; will mean that the frame created for it is left ;; around showing some random buffer, and next time we ;; pop to the debugger buffer we'll create yet ;; another frame. ;; If debugger-will-be-back is non-nil, the frame ;; would need to be de-iconified anyway immediately ;; after when we re-enter the debugger, so iconifying it ;; here would cause flashing. ;; Use quit-window rather than bury-buffer to quieten ;; Drew Adams. --Stef (quit-window)))) To speak to the comment about Drew Adams: Before this was changed to quit-window, things were even worse - iconifying (with the flashing mentioned) and bury-buffer were tried. Multiple debugger frames were created, reproducing like rabbits. Stefan fixed that problem by using quit-window, which is much better than the previous Emacs 22 behavior - but it is still worse than what Emacs 20 and 21 did: *nothing*. Could we please go back to the Emacs 21 behavior in the case of a dedicated, one-window-p frame - just leave the buffer and frame alone? If not, please leave the code alone. quit-window is a pain for me, but it is a lot less of a pain than flashing, iconifying, or burying - I don't want to risk having something like that again. If we could make the change back to the simpler behavior for dedicated windows, that would be great. Thanks. BTW - Judging by appearances, the `debug' function code is a bit haggard. It seems to have been poked and tweaked to death, without ever having been rewritten.