From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Pete Beardmore Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jun 2011 17:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.130703566114475 (code B ref -1); Thu, 02 Jun 2011 17:28:02 +0000 Received: (at submit) by debbugs.gnu.org; 2 Jun 2011 17:27:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSBgK-0003lQ-9v for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:40 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSBgE-0003lA-Ow for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSBg8-0003GZ-6c for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_NONE,RECEIVED_FROM_WINDOWS_HOST, RFC_ABUSE_POST,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg7-0003GV-T6 for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:27 -0400 Received: from eggs.gnu.org ([140.186.70.92]:50997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg6-0006PT-47 for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSBg2-0003Fs-T5 for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:25 -0400 Received: from blu0-omc1-s14.blu0.hotmail.com ([65.55.116.25]:19889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg2-0003FW-Jy for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:22 -0400 Received: from BLU0-SMTP178 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Jun 2011 10:07:19 -0700 X-Originating-IP: [78.86.149.244] X-Originating-Email: [pete.beardmore@msn.com] Message-ID: Received: from elservo.localdomain ([78.86.149.244]) by BLU0-SMTP178.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Jun 2011 10:07:18 -0700 Received: by elservo.localdomain (Postfix, from userid 80) id BB06FADAB0; Thu, 2 Jun 2011 18:07:16 +0100 (BST) Received: from elbeardo.lemondedelabarbe (elbeardo.lemondedelabarbe [10.0.0.5]) by elservo.lemondedelabarbe (Horde Framework) with HTTP; Thu, 02 Jun 2011 18:07:16 +0100 Date: Thu, 2 Jun 2011 18:07:16 +0100 From: Pete Beardmore MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; delsp=Yes; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-OriginalArrivalTime: 02 Jun 2011 17:07:19.0097 (UTC) FILETIME=[87C28A90:01CC2147] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP4, XP SP1+ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Hi, A couple of my frame window layouts cause the emacs debugger's backtrace buffer to cycle between several windows when stepping through code, making it very difficult to focus. Please follow the minimal steps below to re-produce this undesirable behaviour, also confirmed as present by another user (#emacs 'off-by-1') in a 'relatively recent git version'.. emacs -q C-x 3 C-x 2 M-x debug-on-entry RET apropos RET M-x apropos RET x RET d RET d RET ..you should see the buffer alternate windows on each step through the code. Thanks, Pete. In GNU Emacs 23.3.1 (i486-slackware-linux-gnu, GTK+ Version 2.24.1) of 2011-03-12 on midas Windowing system distributor `The X.Org Foundation', version 11.0.10899906 configured using `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--program-prefix=' '--program-suffix=' '--mandir=/usr/man' '--infodir=/usr/info' '--enable-static=no' '--enable-shared=yes' '--with-x' '--with-x-toolkit=gtk' '--build=i486-slackware-linux' 'build_alias=i486-slackware-linux' 'CFLAGS=-O2 -march=i486 -mtune=i686'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x 3 C-x 2 M-x d e b u g - o n - e n t r y a p r o p o s M-x a p r o p o x d d M-x C-g C-] M-x r e p o r t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Loading apropos...done Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Quit Quit Load-path shadows: ./cedet/cedet-ediff hides ./cedet-1.1bzr8044/cedet-ediff ./cedet/cedet-update-version hides ./cedet-1.1bzr8044/cedet-update-version ./cedet/cedet-build hides ./cedet-1.1bzr8044/cedet-build ./cedet/cedet-update-changelog hides ./cedet-1.1bzr8044/cedet-update-changelog /usr/share/emacs/site-lisp/t-mouse hides /usr/share/emacs/23.3/lisp/t-mouse Features: (shadow sort mail-extr message idna sendmail regexp-opt ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view apropos debug tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind font-render-setting gtk x-toolkit x multi-tty emacs) From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jun 2011 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Pete Beardmore'" , <8789@debbugs.gnu.org> Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.130703766520581 (code B ref 8789); Thu, 02 Jun 2011 18:02:02 +0000 Received: (at 8789) by debbugs.gnu.org; 2 Jun 2011 18:01:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSCCe-0005Ls-7s for submit@debbugs.gnu.org; Thu, 02 Jun 2011 14:01:04 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSCCc-0005LK-Is for 8789@debbugs.gnu.org; Thu, 02 Jun 2011 14:01:03 -0400 Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p52I0sHD019074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 18:00:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p52I0rB7003037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 18:00:54 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p52I0m0c000399; Thu, 2 Jun 2011 13:00:48 -0500 Received: from dradamslap1 (/10.159.46.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Jun 2011 11:00:47 -0700 From: "Drew Adams" References: Date: Thu, 2 Jun 2011 11:00:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcwhTGTXQKh7tiWpSJG4+RBpa8skAQAAalPQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090209.4DE7CFD9.0007:SCFSTAT5015188,ss=1,fgs=0 X-Spam-Score: -6.5 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.5 (------) > A couple of my frame window layouts cause the emacs debugger's > backtrace buffer to cycle between several windows when stepping > through code, making it very difficult to focus. > > Please follow the minimal steps below to re-produce this undesirable > behaviour, also confirmed as present by another user (#emacs > 'off-by-1') in a 'relatively recent git version'.. > > emacs -q > C-x 3 > C-x 2 > M-x debug-on-entry RET > apropos RET > M-x apropos RET > x RET > d RET > d RET > > ..you should see the buffer alternate windows on each step > through the code. FWIW, I reported this problem long, long ago. I don't recall the bug # (it might have been before we had bug #s), and I can't seem to locate the bug report now. This problem is at least as old as Emacs 20. It can be very distracting. BTW, I notice this happening especially when debugging a command invoked (via a key) from the minibuffer. But your recipe is a good one at top level. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Jun 2011 13:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pete Beardmore Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13071071837205 (code B ref 8789); Fri, 03 Jun 2011 13:20:02 +0000 Received: (at 8789) by debbugs.gnu.org; 3 Jun 2011 13:19:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSUHv-0001s9-2S for submit@debbugs.gnu.org; Fri, 03 Jun 2011 09:19:43 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1QSUHr-0001rw-PA for 8789@debbugs.gnu.org; Fri, 03 Jun 2011 09:19:41 -0400 Received: (qmail invoked by alias); 03 Jun 2011 13:19:32 -0000 Received: from 62-47-33-83.adsl.highway.telekom.at (EHLO [62.47.33.83]) [62.47.33.83] by mail.gmx.net (mp030) with SMTP; 03 Jun 2011 15:19:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+LJPA4k4mL1AQeuYPtxSP2Hr8haoW1NhqwlCcb82 7dFEoeOb1l9zgI Message-ID: <4DE8DF63.5050405@gmx.at> Date: Fri, 03 Jun 2011 15:19:31 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > A couple of my frame window layouts cause the emacs debugger's backtrace > buffer to cycle between several windows when stepping through code, > making it very difficult to focus. > > Please follow the minimal steps below to re-produce this undesirable > behaviour, also confirmed as present by another user (#emacs 'off-by-1') > in a 'relatively recent git version'.. I never use debug and don't have Emacs 23 installed, so I'm probably not of very much help here. > emacs -q > C-x 3 > C-x 2 > M-x debug-on-entry RET > apropos RET > M-x apropos RET > x RET IIUC this shows *backtrace* in the window on the right? > d RET > d RET These steps happen without the RETs I presume? > ..you should see the buffer alternate windows on each step through the > code. On my trunk the *backtrace* buffer is alternately shown in the left lower and the right window, is that what you see? That is, the left upper window is never used? I suppose it happens because `debug' contains this pretty fragile code (save-window-excursion ... (pop-to-buffer debugger-buffer) which I don't understand so I can only speculate. Your three-window setup apparently prevents the creation of a new window so Emacs is forced to reuse an existing one. Now repeating "d" does apparently (1) remove *backtrace* from the window configuration, restoring the previous configuration, and (2) pop to *backtrace* in any but the selected window (which is the left upper one). Now, when it reuses a window, `display-buffer' first tries to use the least-recently-used one, which, in your scenario, is alternatingly one of the two lower windows. You can verify (2) for yourself by replacing the line (or (get-lru-window frame-to-use) in `display-buffer' with the form (or (let ((window (get-lru-window frame-to-use))) (when window (message "%s" window) (sit-for 3) window)) and go through your scenario. I don't have the slightest idea how to fix this though because I don't understand why apparently the *backtrace* buffer is removed from display in (1), and what the subsequent fragment ;; Kill or at least neuter the backtrace buffer, so that users ;; don't try to execute debugger commands in an invalid context. (if (get-buffer-window debugger-buffer 0) ;; 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 (and maybe hide it) but keep it alive. (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. ;; Drew Adams is not happy with this: he wants to frame ;; to be left at the top-level, still working on how ;; best to do that. (bury-buffer)))) (kill-buffer debugger-buffer)) is needed for (despite its detailed comment). So we need help from someone familiar with the debug code :-( martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Jun 2011 15:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org, Pete Beardmore Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13075469817361 (code B ref 8789); Wed, 08 Jun 2011 15:30:03 +0000 Received: (at 8789) by debbugs.gnu.org; 8 Jun 2011 15:29:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QUKhR-0001ug-69 for submit@debbugs.gnu.org; Wed, 08 Jun 2011 11:29:41 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QUKhP-0001uT-1e for 8789@debbugs.gnu.org; Wed, 08 Jun 2011 11:29:39 -0400 Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:34782 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QUKhJ-0002mf-AF; Wed, 08 Jun 2011 11:29:33 -0400 Received: by ceviche.home (Postfix, from userid 20848) id B2223668AA; Wed, 8 Jun 2011 12:29:30 -0300 (ART) From: Stefan Monnier Message-ID: References: <4DE8DF63.5050405@gmx.at> Date: Wed, 08 Jun 2011 12:29:30 -0300 In-Reply-To: <4DE8DF63.5050405@gmx.at> (martin rudalics's message of "Fri, 03 Jun 2011 15:19:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) > I don't have the slightest idea how to fix this though because I don't > understand why apparently the *backtrace* buffer is removed from display > in (1), and what the subsequent fragment > ;; Kill or at least neuter the backtrace buffer, so that users > ;; don't try to execute debugger commands in an invalid context. > (if (get-buffer-window debugger-buffer 0) > ;; 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 (and maybe hide it) but keep it alive. > (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. > ;; Drew Adams is not happy with this: he wants to frame > ;; to be left at the top-level, still working on how > ;; best to do that. > (bury-buffer)))) > (kill-buffer debugger-buffer)) > is needed for (despite its detailed comment). So we need help from > someone familiar with the debug code :-( I don't use `d' but I can explain the reason for the above code: when we exit the debugger, I don't want to leave around an empty fundamental-mode *Debugger* window (which in my case is a dedicated window in a separate frame), so I bury it. BTW, I recently changed the above code in `trunk' so that the kill-buffer is not called if the buffer was pre-existing. Stefan From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Feb 2012 05:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Reply-To: michael_heerdegen@web.de Received: via spool by submit@debbugs.gnu.org id=B.13287654697736 (code B ref -1); Thu, 09 Feb 2012 05:32:01 +0000 Received: (at submit) by debbugs.gnu.org; 9 Feb 2012 05:31:09 +0000 Received: from localhost ([127.0.0.1]:33140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RvMb6-00020h-3D for submit@debbugs.gnu.org; Thu, 09 Feb 2012 00:31:08 -0500 Received: from eggs.gnu.org ([140.186.70.92]:49713) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RvMb2-00020D-IM for submit@debbugs.gnu.org; Thu, 09 Feb 2012 00:31:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvMZt-0002pr-58 for submit@debbugs.gnu.org; Thu, 09 Feb 2012 00:29:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_XBL, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:51727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvMZt-0002pn-3n for submit@debbugs.gnu.org; Thu, 09 Feb 2012 00:29:53 -0500 Received: from eggs.gnu.org ([140.186.70.92]:36979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvMZs-0002gm-4k for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2012 00:29:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvMZr-0002pb-6N for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2012 00:29:52 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:34540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvMZr-0002pN-1f for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2012 00:29:51 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id AA4851C0B7CD1 for ; Thu, 9 Feb 2012 06:29:48 +0100 (CET) Received: from snow.dragon ([89.204.139.232]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0LmLK6-1SU9MX2kFu-00ZccE; Thu, 09 Feb 2012 06:29:48 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> Date: Thu, 09 Feb 2012 06:31:09 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 08 Jun 2011 12:29:30 -0300") Message-ID: <87haz0po82.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:VWhKWKTgz5EaLk3oMXubMShevABSY+YHOuP0F0ESSOl NPSsZBTWIvn8GQBpgZjSIfCI+aboT+A0yIZfPxJw5mmAA57dx8 rwEBkJmB3dJvAr1N9weHMxodHv7nqvsAMj5aXHFto66jE+kwV0 qr9mqsNPJewz1khpNtxZqlbiVbRn1hNGV3vGZLBQSsD/kQcmo5 68zLtYVApOcLeql5tLYtm2f+Rjj+/v7GKBYTY4WGAU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Hello, I don't know why this problem doesn't get fixed. It is an annoying problem, and a fix need not to be complicated - on the contrary. It should IMHO be sufficient to add to the (pop-to-buffer debugger-buffer) call in `debug' an action argument that ensures that always the same window is chosen, by an deterministic algorithm. For example: (pop-to-buffer debugger-buffer '((lambda (buffer _) (let ((first-win (frame-first-window))) (select-window first-win) (switch-to-buffer buffer) first-win)))) would always choose the first window for *Backtrace*. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Feb 2012 18:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: michael_heerdegen@web.de Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132881177121835 (code B ref 8789); Thu, 09 Feb 2012 18:23:02 +0000 Received: (at 8789) by debbugs.gnu.org; 9 Feb 2012 18:22:51 +0000 Received: from localhost ([127.0.0.1]:33994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RvYdv-0005g8-5n for submit@debbugs.gnu.org; Thu, 09 Feb 2012 13:22:51 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:54833) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RvYds-0005fy-U8 for 8789@debbugs.gnu.org; Thu, 09 Feb 2012 13:22:50 -0500 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q19ILdSE006250; Thu, 9 Feb 2012 13:21:39 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 5575C130009; Thu, 9 Feb 2012 13:21:39 -0500 (EST) From: Stefan Monnier Message-ID: References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> Date: Thu, 09 Feb 2012 13:21:39 -0500 In-Reply-To: <87haz0po82.fsf@web.de> (Michael Heerdegen's message of "Thu, 09 Feb 2012 06:31:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4127=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4127> : streams <727147> : uri <1062691> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) > I don't know why this problem doesn't get fixed. It is an annoying > problem, and a fix need not to be complicated - on the contrary. > It should IMHO be sufficient to add to the > (pop-to-buffer debugger-buffer) > call in `debug' an action argument that ensures that always the same > window is chosen, by an deterministic algorithm. For example: > (pop-to-buffer debugger-buffer > '((lambda (buffer _) > (let ((first-win (frame-first-window))) > (select-window first-win) > (switch-to-buffer buffer) > first-win)))) > would always choose the first window for *Backtrace*. The general approach sounds good, but we should probably try to refine it so as to minimize changes in behavior, and so it works right in the multi-frame and even multi-terminal case. We could try to store the last-used-window in a variable `debugger-last-used-window' and use that window after checking that it's still live and is visible in the selected terminal. Stefan From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Feb 2012 18:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: michael_heerdegen@web.de Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132881196522145 (code B ref 8789); Thu, 09 Feb 2012 18:27:02 +0000 Received: (at 8789) by debbugs.gnu.org; 9 Feb 2012 18:26:05 +0000 Received: from localhost ([127.0.0.1]:33998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RvYh2-0005l8-Rv for submit@debbugs.gnu.org; Thu, 09 Feb 2012 13:26:05 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:45618) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1RvYh0-0005ka-9k for 8789@debbugs.gnu.org; Thu, 09 Feb 2012 13:26:03 -0500 Received: (qmail invoked by alias); 09 Feb 2012 18:24:47 -0000 Received: from 62-47-47-1.adsl.highway.telekom.at (EHLO [62.47.47.1]) [62.47.47.1] by mail.gmx.net (mp020) with SMTP; 09 Feb 2012 19:24:47 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19b945LWpVb65ekQSYokyFMOxTbHk/me4xpA9SoWd jZlbdvWZ7Spe5l Message-ID: <4F340F6C.7060804@gmx.at> Date: Thu, 09 Feb 2012 19:24:44 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> In-Reply-To: <87haz0po82.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > It should IMHO be sufficient to add to the > > (pop-to-buffer debugger-buffer) > > call in `debug' an action argument that ensures that always the same > window is chosen, by an deterministic algorithm. For example: > > (pop-to-buffer debugger-buffer > '((lambda (buffer _) > (let ((first-win (frame-first-window))) > (select-window first-win) > (switch-to-buffer buffer) > first-win)))) > > would always choose the first window for *Backtrace*. Have you tried adding an according rule to `display-buffer-alist'? martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Feb 2012 00:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13289184369992 (code B ref -1); Sat, 11 Feb 2012 00:01:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2012 00:00:36 +0000 Received: from localhost ([127.0.0.1]:35425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rw0OK-0002b7-GC for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:00:36 -0500 Received: from eggs.gnu.org ([140.186.70.92]:59873) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rw0OI-0002ar-Ro for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:00:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw0Mz-0001J7-Aq for submit@debbugs.gnu.org; Fri, 10 Feb 2012 18:59:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:34660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0Mz-0001J3-9S for submit@debbugs.gnu.org; Fri, 10 Feb 2012 18:59:13 -0500 Received: from eggs.gnu.org ([140.186.70.92]:52826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0My-0006LX-Ba for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 18:59:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw0Mw-0001In-R5 for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 18:59:12 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:45123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0Mw-0001Ig-IN for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 18:59:10 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id 346F61C0ED955 for ; Sat, 11 Feb 2012 00:59:09 +0100 (CET) Received: from snow.dragon ([82.113.121.242]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0LbZpT-1SOh9j0IDz-00kMzc; Sat, 11 Feb 2012 00:59:08 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F340F6C.7060804@gmx.at> Date: Sat, 11 Feb 2012 01:00:30 +0100 In-Reply-To: <4F340F6C.7060804@gmx.at> (martin rudalics's message of "Thu, 09 Feb 2012 19:24:44 +0100") Message-ID: <87zkcqgrxd.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:5sBZ6idcFXLHm4QB4Ac25k+vgnnT/vOfL+jS4cFRvam cw4vWdAHyklMH8+baQS6thfyTpjD3pVbyfGvLGLNkfQEgEZrf1 00lqZPkUjE58zlwWSe4+O3PS9W1iHuVhhT1gWG0iuunhTwwUUK lR1zUH+johJ7whs4k2vObMrO8+/+1J8v/0pqattxyywNpPaJdD kk2bAqZR5gMHoq1fP1QKFei+cQOHhjcWxaQsj3hmtQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) martin rudalics writes: > > (pop-to-buffer debugger-buffer > > '((lambda (buffer _) > > (let ((first-win (frame-first-window))) > > (select-window first-win) > > (switch-to-buffer buffer) > > first-win)))) > > > > would always choose the first window for *Backtrace*. > > Have you tried adding an according rule to `display-buffer-alist'? Yes, that also works for me. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Feb 2012 00:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132891867910337 (code B ref -1); Sat, 11 Feb 2012 00:05:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Feb 2012 00:04:39 +0000 Received: from localhost ([127.0.0.1]:35432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rw0SD-0002ge-Qt for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:04:38 -0500 Received: from eggs.gnu.org ([140.186.70.92]:35517) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rw0SB-0002gR-1L for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:04:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw0Qr-0001jd-H5 for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:03:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:49751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0Qr-0001jZ-Fk for submit@debbugs.gnu.org; Fri, 10 Feb 2012 19:03:13 -0500 Received: from eggs.gnu.org ([140.186.70.92]:32801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0Qq-0007EJ-Js for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 19:03:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw0Qp-0001iy-7O for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 19:03:12 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:55553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0Qo-0001ia-QC for bug-gnu-emacs@gnu.org; Fri, 10 Feb 2012 19:03:11 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate01.web.de (Postfix) with ESMTP id 80E841AA3B693 for ; Sat, 11 Feb 2012 01:03:09 +0100 (CET) Received: from snow.dragon ([82.113.121.242]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0MddXQ-1SAMym2hmW-00POnM; Sat, 11 Feb 2012 01:03:09 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> Date: Sat, 11 Feb 2012 01:04:29 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 09 Feb 2012 13:21:39 -0500") Message-ID: <87vcnegrqq.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:jk/EblanqrWvejsIrLeyicg0GUSvSP8f18dhMG+n+A3 A04uD5x5v51/4hFxmeYF61DgQCGTEUYMH9+0mZcLdAB6OlKVXb g1cbqd/+X33ei6FaWRHob5eY5XYs/Y6lYCY89oTbX+xupmuFrF i8aVhjd1IUqspWzyd/Nw6cIBcGgeM0ILVRmdHOdGxslZKqflNP azscE5EGEPrQBNxZVGXCYcAYV9X690CCC9k/E/W4Os= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Stefan Monnier writes: > The general approach sounds good, but we should probably try to refine > it so as to minimize changes in behavior, and so it works right in the > multi-frame and even multi-terminal case. > > We could try to store the last-used-window in a variable > `debugger-last-used-window' and use that window after checking that it's > still live and is visible in the selected terminal. Sounds really good to me, and not hard to implement. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Feb 2012 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13293253868869 (code B ref 8789); Wed, 15 Feb 2012 17:04:02 +0000 Received: (at 8789) by debbugs.gnu.org; 15 Feb 2012 17:03:06 +0000 Received: from localhost ([127.0.0.1]:41647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RxiFy-0002Im-7Z for submit@debbugs.gnu.org; Wed, 15 Feb 2012 12:03:06 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:38797) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1RxiFp-0002IK-Td for 8789@debbugs.gnu.org; Wed, 15 Feb 2012 12:03:00 -0500 Received: (qmail invoked by alias); 15 Feb 2012 17:01:02 -0000 Received: from 62-47-42-178.adsl.highway.telekom.at (EHLO [62.47.42.178]) [62.47.42.178] by mail.gmx.net (mp032) with SMTP; 15 Feb 2012 18:01:02 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/6sLUYhTX6YMuVfTPbC8GMU5hmvsCyKpQBoRpTYt f4QHjW/QKYME9E Message-ID: <4F3BE4CB.3030909@gmx.at> Date: Wed, 15 Feb 2012 18:00:59 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > The general approach sounds good, but we should probably try to refine > it so as to minimize changes in behavior, and so it works right in the > multi-frame and even multi-terminal case. > > We could try to store the last-used-window in a variable > `debugger-last-used-window' and use that window after checking that it's > still live and is visible in the selected terminal. We could also try `window-prev-buffers' and `window-next-buffers' as in the rather untested patch below. martin === modified file 'lisp/window.el' --- lisp/window.el 2012-02-12 05:10:30 +0000 +++ lisp/window.el 2012-02-15 16:54:41 +0000 @@ -4846,6 +4846,39 @@ (and pop-up-windows (display-buffer-pop-up-window buffer alist)))) +(defun window-previously-showing (buffer &optional all-frames dedicated) + "Return a window that previously showed BUFFER. +A minibuffer window is never a candidate. A dedicated window is +never a candidate unless DEDICATED is non-nil, so if all windows +are dedicated, the value is nil. Avoid returning the selected +window if possible. + +The following non-nil values of the optional argument ALL-FRAMES +have special meanings: + +- t means consider all windows on all existing frames. + +- `visible' means consider all windows on all visible frames on + the current terminal. + +- 0 (the number zero) means consider all windows on all visible + and iconified frames on the current terminal. + +- A frame means consider all windows on that frame only. + +Any other value of ALL-FRAMES means consider all windows on the +selected frame and no others." + (let (best-window second-best-window) + (dolist (window (window-list-1 nil 'nomini all-frames)) + (when (and (or (assq buffer (window-prev-buffers window)) + (assq buffer (window-next-buffers window))) + (or dedicated (not (window-dedicated-p window)))) + (if (eq window (selected-window)) + (setq second-best-window window) + ;; We probably should throw WINDOW here. + (setq best-window window)))) + (or best-window second-best-window))) + (defun display-buffer-use-some-window (buffer alist) "Display BUFFER in an existing window. Search for a usable window, set that window to the buffer, and @@ -4864,7 +4897,8 @@ (unwind-protect (setq window ;; Reuse an existing window. - (or (get-lru-window frame) + (or (window-previously-showing buffer 'visible) + (get-lru-window frame) (let ((window (get-buffer-window buffer 'visible))) (unless (and not-this-window (eq window (selected-window))) From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Feb 2012 19:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132933282720241 (code B ref 8789); Wed, 15 Feb 2012 19:08:01 +0000 Received: (at 8789) by debbugs.gnu.org; 15 Feb 2012 19:07:07 +0000 Received: from localhost ([127.0.0.1]:41792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RxkC3-0005GQ-71 for submit@debbugs.gnu.org; Wed, 15 Feb 2012 14:07:07 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:40737) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RxkC1-0005GD-Jy for 8789@debbugs.gnu.org; Wed, 15 Feb 2012 14:07:06 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q1FJ5HhK016518; Wed, 15 Feb 2012 14:05:18 -0500 Received: by pastel.home (Postfix, from userid 20848) id 36B335929A; Wed, 15 Feb 2012 14:05:17 -0500 (EST) From: Stefan Monnier Message-ID: References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> Date: Wed, 15 Feb 2012 14:05:17 -0500 In-Reply-To: <4F3BE4CB.3030909@gmx.at> (martin rudalics's message of "Wed, 15 Feb 2012 18:00:59 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4133=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4133> : streams <728941> : uri <1066027> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) > We could also try `window-prev-buffers' and `window-next-buffers' as in > the rather untested patch below. Sounds good for the backtrace buffer, but the patch you propose would affect many more cases, and while I think it might be good to do it globally like you suggest, I wouldn't want to make such a change so late in the pretest. Can you provide another patch that limits the effect to the backtrace buffer? Stefan > === modified file 'lisp/window.el' > --- lisp/window.el 2012-02-12 05:10:30 +0000 > +++ lisp/window.el 2012-02-15 16:54:41 +0000 > @@ -4846,6 +4846,39 @@ > (and pop-up-windows > (display-buffer-pop-up-window buffer alist)))) > +(defun window-previously-showing (buffer &optional all-frames dedicated) > + "Return a window that previously showed BUFFER. > +A minibuffer window is never a candidate. A dedicated window is > +never a candidate unless DEDICATED is non-nil, so if all windows > +are dedicated, the value is nil. Avoid returning the selected > +window if possible. > + > +The following non-nil values of the optional argument ALL-FRAMES > +have special meanings: > + > +- t means consider all windows on all existing frames. > + > +- `visible' means consider all windows on all visible frames on > + the current terminal. > + > +- 0 (the number zero) means consider all windows on all visible > + and iconified frames on the current terminal. > + > +- A frame means consider all windows on that frame only. > + > +Any other value of ALL-FRAMES means consider all windows on the > +selected frame and no others." > + (let (best-window second-best-window) > + (dolist (window (window-list-1 nil 'nomini all-frames)) > + (when (and (or (assq buffer (window-prev-buffers window)) > + (assq buffer (window-next-buffers window))) > + (or dedicated (not (window-dedicated-p window)))) > + (if (eq window (selected-window)) > + (setq second-best-window window) > + ;; We probably should throw WINDOW here. > + (setq best-window window)))) > + (or best-window second-best-window))) > + > (defun display-buffer-use-some-window (buffer alist) > "Display BUFFER in an existing window. > Search for a usable window, set that window to the buffer, and > @@ -4864,7 +4897,8 @@ > (unwind-protect > (setq window > ;; Reuse an existing window. > - (or (get-lru-window frame) > + (or (window-previously-showing buffer 'visible) > + (get-lru-window frame) > (let ((window (get-buffer-window buffer 'visible))) > (unless (and not-this-window > (eq window (selected-window))) From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2012 08:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132937951331046 (code B ref 8789); Thu, 16 Feb 2012 08:06:02 +0000 Received: (at 8789) by debbugs.gnu.org; 16 Feb 2012 08:05:13 +0000 Received: from localhost ([127.0.0.1]:42133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RxwL2-00084h-Ml for submit@debbugs.gnu.org; Thu, 16 Feb 2012 03:05:12 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:34030) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1RxwKz-00084N-Ua for 8789@debbugs.gnu.org; Thu, 16 Feb 2012 03:05:11 -0500 Received: (qmail invoked by alias); 16 Feb 2012 08:03:17 -0000 Received: from 62-47-33-194.adsl.highway.telekom.at (EHLO [62.47.33.194]) [62.47.33.194] by mail.gmx.net (mp004) with SMTP; 16 Feb 2012 09:03:17 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/2HdF1qBz2vcAgtENx9mrSVfW9uSsAVFeYW1xkzP Bd7ttu1braCrGq Message-ID: <4F3CB843.6030401@gmx.at> Date: Thu, 16 Feb 2012 09:03:15 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Sounds good for the backtrace buffer, but the patch you propose would > affect many more cases, and while I think it might be good to do it > globally like you suggest, I wouldn't want to make such a change so late > in the pretest. Neither do I. The problem is that if a window is not very suitable for getting reused, there's no easy way for the user (or the application) to communicate that to the buffer display routines. > Can you provide another patch that limits the effect to the > backtrace buffer? Can you? I think that using `display-buffer-overriding-action' would be too harsh so we would have to specify this via the ACTION argument in (pop-to-buffer debugger-buffer). A patch in that direction is below. martin === modified file 'lisp/emacs-lisp/debug.el' --- lisp/emacs-lisp/debug.el 2012-01-19 07:21:25 +0000 +++ lisp/emacs-lisp/debug.el 2012-02-16 07:51:35 +0000 @@ -194,7 +194,9 @@ ;; Place an extra debug-on-exit for macro's. (when (eq 'lambda (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) - (pop-to-buffer debugger-buffer) + (pop-to-buffer + debugger-buffer + '((display-buffer-in-window-previously-showing-it . nil))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive === modified file 'lisp/window.el' --- lisp/window.el 2012-02-12 05:10:30 +0000 +++ lisp/window.el 2012-02-16 07:54:35 +0000 @@ -4846,6 +4846,22 @@ (and pop-up-windows (display-buffer-pop-up-window buffer alist)))) +(defun display-buffer-in-window-previously-showing-it (buffer &optional alist) + "Display BUFFER in a window previously showing it." + (let (best-window second-best-window window) + (catch 'best-window + (dolist (window (window-list-1 nil 'nomini 'visible)) + (when (and (assq buffer (window-prev-buffers window)) + (not (window-dedicated-p window))) + (if (eq window (selected-window)) + (setq second-best-window window) + (setq best-window window) + (throw 'best-window t))))) + + (when (setq window (or best-window second-best-window)) + (display-buffer-record-window 'reuse window buffer) + (window--display-buffer-2 buffer window display-buffer-mark-dedicated)))) + (defun display-buffer-use-some-window (buffer alist) "Display BUFFER in an existing window. Search for a usable window, set that window to the buffer, and From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2012 13:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13294004572827 (code B ref 8789); Thu, 16 Feb 2012 13:55:02 +0000 Received: (at 8789) by debbugs.gnu.org; 16 Feb 2012 13:54:17 +0000 Received: from localhost ([127.0.0.1]:42373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ry1mr-0000jY-2l for submit@debbugs.gnu.org; Thu, 16 Feb 2012 08:54:17 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:50294) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ry1mo-0000jQ-2G for 8789@debbugs.gnu.org; Thu, 16 Feb 2012 08:54:14 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q1GDqPbr025824; Thu, 16 Feb 2012 08:52:25 -0500 Received: by pastel.home (Postfix, from userid 20848) id D3CA35929A; Thu, 16 Feb 2012 08:52:24 -0500 (EST) From: Stefan Monnier Message-ID: References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> Date: Thu, 16 Feb 2012 08:52:24 -0500 In-Reply-To: <4F3CB843.6030401@gmx.at> (martin rudalics's message of "Thu, 16 Feb 2012 09:03:15 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4133=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4133> : streams <729212> : uri <1066519> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) >> Can you provide another patch that limits the effect to the >> backtrace buffer? > Can you? I think that using `display-buffer-overriding-action' would be > too harsh so we would have to specify this via the ACTION argument in > (pop-to-buffer debugger-buffer). A patch in that direction is below. Looks fine to me, feel free to install, thank you very much, Stefan From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2012 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org, Pete Beardmore Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132941474530318 (code B ref 8789); Thu, 16 Feb 2012 17:53:02 +0000 Received: (at 8789) by debbugs.gnu.org; 16 Feb 2012 17:52:25 +0000 Received: from localhost ([127.0.0.1]:42787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ry5VH-0007sw-Me for submit@debbugs.gnu.org; Thu, 16 Feb 2012 12:52:24 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:53989) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Ry5VB-0007sa-F5 for 8789@debbugs.gnu.org; Thu, 16 Feb 2012 12:52:19 -0500 Received: (qmail invoked by alias); 16 Feb 2012 17:50:22 -0000 Received: from 62-47-33-194.adsl.highway.telekom.at (EHLO [62.47.33.194]) [62.47.33.194] by mail.gmx.net (mp069) with SMTP; 16 Feb 2012 18:50:22 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18YX6Bt1cEY0yaNN/B8lMFaHZM84XNwscJVPmdDJG LeeO6IbjSmuASM Message-ID: <4F3D41DD.6080603@gmx.at> Date: Thu, 16 Feb 2012 18:50:21 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Could someone (Pete, Michael) check whether the patch fixes the original problem? Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2012 21:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org Reply-To: michael_heerdegen@web.de Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132942922319741 (code B ref 8789); Thu, 16 Feb 2012 21:54:01 +0000 Received: (at 8789) by debbugs.gnu.org; 16 Feb 2012 21:53:43 +0000 Received: from localhost ([127.0.0.1]:42970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ry9Gp-00058M-7p for submit@debbugs.gnu.org; Thu, 16 Feb 2012 16:53:43 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:56656) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ry9Gl-000588-GE for 8789@debbugs.gnu.org; Thu, 16 Feb 2012 16:53:41 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate01.web.de (Postfix) with ESMTP id 99F741ABC86FF for <8789@debbugs.gnu.org>; Thu, 16 Feb 2012 22:51:43 +0100 (CET) Received: from snow.dragon ([89.204.130.243]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0LfzgJ-1SIIZ306VX-00oncf; Thu, 16 Feb 2012 22:51:43 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> Date: Thu, 16 Feb 2012 22:53:04 +0100 In-Reply-To: <4F3D41DD.6080603@gmx.at> (martin rudalics's message of "Thu, 16 Feb 2012 18:50:21 +0100") Message-ID: <877gzmqwcf.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:pH5rRcS6Ts39HqW5SVxYJgZrTxy0/mnR9+xj9jfUir2 7mgYgHMxN/qZYyw8+0GEiYOxCq5yV3x0wGMwXkB0HiAfJN2q5Y QZ5/s8Q/5G5g7UQfI88i9frVjW551luxfxFIKchEIZyTWHLvx7 ZKaGOnz5AAKBN3AH71Jo/uXL1Eu97OzujVItYrW882HFp1OuIF telf8rO2BSzHgZ2NYEuuHWWXwNwAio/DvLSz2eL6DM= X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) martin rudalics writes: > Could someone (Pete, Michael) check whether the patch fixes the > original problem? I tested about 2 hours and encountered many problems. At first, some general things: (1) If the user starts the debugger, do we really want that the Backtrace buffer pops up in some other frame only because it was displayed there in some window before? (2) A problem with this approach: if the Backtrace buffer was already visible in several windows, it still hops around, because the window `display-buffer-in-window-previously-showing-it' returns is not unique. Now to my tests in detail: - When I start debugging with a 3-windowed frame, and this is the first time at all that I use the debugger at all, even then, the debugger hops around. This has to do with (1), but I don't know why it hops the first time. But it gets much worse. Do the following: - emacs -Q - require 'debug, and load your patch - M-x debug-on-entry dired RET - C-x d RET - hit d three times -> Emacs crashs! This is reproducible here. I use GNU Emacs 24.0.93.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka, modified by Debian, btw. This is all a horror to debug. Tell me if I can help with something. Michael From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2012 10:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: michael_heerdegen@web.de Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.132947284423159 (code B ref 8789); Fri, 17 Feb 2012 10:01:02 +0000 Received: (at 8789) by debbugs.gnu.org; 17 Feb 2012 10:00:44 +0000 Received: from localhost ([127.0.0.1]:43345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RyKcN-00061T-Kc for submit@debbugs.gnu.org; Fri, 17 Feb 2012 05:00:43 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:55294) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1RyKcJ-00061F-Up for 8789@debbugs.gnu.org; Fri, 17 Feb 2012 05:00:41 -0500 Received: (qmail invoked by alias); 17 Feb 2012 09:58:41 -0000 Received: from 62-47-62-21.adsl.highway.telekom.at (EHLO [62.47.62.21]) [62.47.62.21] by mail.gmx.net (mp040) with SMTP; 17 Feb 2012 10:58:41 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18KAzN1pKsKy5Fec15ylvyZhBMlLvYeDR3k0xz2ph pLVFlMYSPfchbQ Message-ID: <4F3E24CA.9080305@gmx.at> Date: Fri, 17 Feb 2012 10:58:34 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> In-Reply-To: <877gzmqwcf.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I tested about 2 hours Thank you! > and encountered many problems. > > At first, some general things: > > (1) If the user starts the debugger, do we really want that the > Backtrace buffer pops up in some other frame only because it was > displayed there in some window before? Maybe not. But we should also handle the case of the user preferring *Backtrace* to appear on a standalone frame. Detecting this (from within `debug') is tricky. > (2) A problem with this approach: if the Backtrace buffer was already > visible in several windows, it still hops around, because the > window `display-buffer-in-window-previously-showing-it' returns is > not unique. I see. The first argument in the call of `window-list-1' could be made the `frame-first-window' of the selected frame. Can you try that, i.e., using a call like (dolist (window (window-list-1 (frame-first-window) 'nomini 'visible)) and, if you want to avoid the frame problem above as well, (dolist (window (window-list-1 (frame-first-window) 'nomini)) Or is it because the window where the *Backtrace* buffer earlier appeared is the selected one? Would it be OK to return the selected window here if there's another choice? BTW so far I don't handle the case yet where the *Backtrace* buffer is already shown in some window. > Now to my tests in detail: > > - When I start debugging with a 3-windowed frame, and this is the first > time at all that I use the debugger at all, even then, the debugger > hops around. This has to do with (1), but I don't know why it hops > the first time. IIUC so far by "hop around" we meant the *Backtrace* buffer appearing in one window and then in another. How can the debugger "hop around" if *Backtrace* hasn't been shown yet? > But it gets much worse. Do the following: > > - emacs -Q > - require 'debug, and load your patch > - M-x debug-on-entry dired RET > - C-x d RET > - hit d three times -> Emacs crashs! > > This is reproducible here. I use GNU Emacs 24.0.93.1 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka, > modified by Debian, btw. I can't reproduce that here (on Windows XP). After C-x d I get the *Backtrace* buffer in the bottom window, hitting "d" now steps through the code. Please try to get a backtrace of this. > This is all a horror to debug. Debugging a debugger is painful. Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Feb 2012 18:46:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: michael_heerdegen@web.de Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.1330109154762 (code B ref 8789); Fri, 24 Feb 2012 18:46:03 +0000 Received: (at 8789) by debbugs.gnu.org; 24 Feb 2012 18:45:54 +0000 Received: from localhost ([127.0.0.1]:54484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S109S-0000CF-BW for submit@debbugs.gnu.org; Fri, 24 Feb 2012 13:45:54 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:39505) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1S109P-0000By-3Y for 8789@debbugs.gnu.org; Fri, 24 Feb 2012 13:45:52 -0500 Received: (qmail invoked by alias); 24 Feb 2012 18:43:09 -0000 Received: from 62-47-54-173.adsl.highway.telekom.at (EHLO [62.47.54.173]) [62.47.54.173] by mail.gmx.net (mp019) with SMTP; 24 Feb 2012 19:43:09 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/f3EhkAEHfiA/AreafSRsG0v0fHPVQITaDm7iten I7VIS+/n4pbBu0 Message-ID: <4F47DA33.5070804@gmx.at> Date: Fri, 24 Feb 2012 19:42:59 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> In-Reply-To: <877gzmqwcf.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > At first, some general things: > > (1) If the user starts the debugger, do we really want that the > Backtrace buffer pops up in some other frame only because it was > displayed there in some window before? > > (2) A problem with this approach: if the Backtrace buffer was already > visible in several windows, it still hops around, because the > window `display-buffer-in-window-previously-showing-it' returns is > not unique. > > > Now to my tests in detail: > > - When I start debugging with a 3-windowed frame, and this is the first > time at all that I use the debugger at all, even then, the debugger > hops around. This has to do with (1), but I don't know why it hops > the first time. I finally managed to look into this issue and it's non-trivial for two reasons: (A) `debug' wraps all interesting actions in a `save-window-excursion'. Since `set-window-configuration' does not use `set-window-buffer' to restore the old buffer, it does not call `record-window-buffer' either. This means that *Backtrace*, when displayed by `debug' only, never ends up on the previous buffers list of any window that shows it. This explains why the debugger "hops the first time". (B) When the debugger buffer has not existed before calling `debug', the line (kill-buffer debugger-buffer) will kill it and remove it from the previous buffers lists of all windows (this is needed to avoid that these lists get arbitrarily large). In this case there's no way to find a window where the buffer was shown previously. (A) can be fixed easily by having `set-window-configuration' record the buffer it's going to replace by the saved one. So if we avoid killing the buffer in (B) all issues cited above can be resolved. > But it gets much worse. Do the following: > > - emacs -Q > - require 'debug, and load your patch > - M-x debug-on-entry dired RET > - C-x d RET > - hit d three times -> Emacs crashs! > > This is reproducible here. I use GNU Emacs 24.0.93.1 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka, > modified by Debian, btw. > > > This is all a horror to debug. Tell me if I can help with something. This must be a different issue. Please get a backtrace of this ASAP. Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Feb 2012 23:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.133047303412145 (code B ref 8789); Tue, 28 Feb 2012 23:51:01 +0000 Received: (at 8789) by debbugs.gnu.org; 28 Feb 2012 23:50:34 +0000 Received: from localhost ([127.0.0.1]:54875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S2WoS-00039b-1X for submit@debbugs.gnu.org; Tue, 28 Feb 2012 18:50:34 -0500 Received: from fmmailgate06.web.de ([217.72.192.247]:58827) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S2WoC-00038q-UV for 8789@debbugs.gnu.org; Tue, 28 Feb 2012 18:50:21 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate06.web.de (Postfix) with ESMTP id 74BDFD36A51 for <8789@debbugs.gnu.org>; Wed, 29 Feb 2012 00:50:00 +0100 (CET) Received: from dragon.dragon ([94.216.111.15]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0M6Df8-1SMxPL1JEo-00y2tf; Wed, 29 Feb 2012 00:50:00 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <4F47DA33.5070804@gmx.at> Date: Wed, 29 Feb 2012 00:56:04 +0100 In-Reply-To: <4F47DA33.5070804@gmx.at> (martin rudalics's message of "Fri, 24 Feb 2012 19:42:59 +0100") Message-ID: <86r4xev7fv.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V02:K0:QKIYQt/QD9Nm55FDp0tOe7o+7L51hcZER89K8q/T2nP PEVq4nRDzB2+1DU2mpTAyWl+WRUs7FUorhWjCBtGE47rYwQWUi xC44hqY9Gv5qHKI3wpxbadiK/G8fTl6eeD0ynjtUkkR5Rf+Qlg V/IK8Su1a5+s6kYoyAJ6t0dUBqUyyoYycsp0ChUpN4Q6xN5ozR 4luvw3LP4tC0S+KGlYtH2DWZmTq8zlCm8Vy6EEcGJg= X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) --=-=-= Content-Type: text/plain martin rudalics writes: > > But it gets much worse. Do the following: > > > > - emacs -Q > > - require 'debug, and load your patch > > - M-x debug-on-entry dired RET > > - C-x d RET > > - hit d three times -> Emacs crashs! > > > This must be a different issue. Please get a backtrace of this ASAP. Here it comes, produced today with "GNU Emacs 24.0.93.1 (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-22 on zelenka, modified by Debian". --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=debug.txt Content-Transfer-Encoding: quoted-printable Content of *Backtrace* before the crash: * (set-window-configuration wconfig) (unwind-protect (progn (with-no-warnings (setq unread-command-char -1)) (= when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq= (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t= ))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previo= usly-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (= when noninteractive (when (> (count-lines (point-min) (point-max)) debugger= -batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch= -max-lines)) (let ((middlestart (point))) (goto-char (point-max)) (forward-= line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-lines)) (delete-r= egion middlestart (point))) (insert "...\n")) (goto-char (point-min)) (mess= age "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-out= put nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit= )))) (set-window-configuration wconfig)) (let ((wconfig (current-window-configuration))) (unwind-protect (progn (w= ith-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args= ) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (= cadr ...))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote (= (display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugg= er-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (= point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (= forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart ...)) (goto= -char (point-max)) (forward-line (- ... debugger-batch-max-lines)) (delete-= region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (mes= sage "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-ou= tput nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edi= t)))) (set-window-configuration wconfig))) (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (= when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq= (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t= ))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previo= usly-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (= when noninteractive (when (> (count-lines (point-min) (point-max)) debugger= -batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch= -max-lines)) (let ((middlestart (point))) (goto-char (point-max)) (forward-= line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-lines)) (delete-r= egion middlestart (point))) (insert "...\n")) (goto-char (point-min)) (mess= age "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-out= put nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit= )))) (save-excursion (save-window-excursion (with-no-warnings (setq unread-com= mand-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debu= g 4 t) (when (eq (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (bac= ktrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-= in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer = debugger-args) (when noninteractive (when (> (count-lines (point-min) (poin= t-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ = 2 debugger-batch-max-lines)) (let ((middlestart (point))) (goto-char (point= -max)) (forward-line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-l= ines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (p= oint-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (le= t ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion= (recursive-edit))))) (unwind-protect (save-excursion (save-window-excursion (with-no-warnings = (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug))= (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr ...))) (bac= ktrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-= in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer = debugger-args) (when noninteractive (when (> (count-lines (point-min) (poin= t-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ = 2 debugger-batch-max-lines)) (let ((middlestart ...)) (goto-char (point-max= )) (forward-line (- ... debugger-batch-max-lines)) (delete-region middlesta= rt (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffe= r-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffe= r-read-only t)) (message "") (save-excursion (recursive-edit))))) (if (get-= buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (with= -selected-window (get-buffer-window debugger-buffer 0) (when (and (window-d= edicated-p (selected-window)) (not debugger-will-be-back)) (bury-buffer))))= (unless debugger-previous-state (kill-buffer debugger-buffer))) (when (buf= fer-live-p debugger-buffer) (with-current-buffer debugger-buffer (let ((inh= ibit-read-only t)) (erase-buffer) (if (null debugger-previous-state) (funda= mental-mode) (insert (nth 1 debugger-previous-state)) (funcall (nth 0 debug= ger-previous-state)))))) (with-timeout-unsuspend debugger-with-timeout-susp= end) (set-match-data debugger-outer-match-data)) (let ((last-command nil) this-command track-mouse (inhibit-trace t) (inhi= bit-debug-on-entry t) unread-command-events unread-post-input-method-events= last-input-event last-command-event last-nonmenu-event last-event-frame ov= erriding-local-map load-read-function (enable-recursive-minibuffers (or ena= ble-recursive-minibuffers (> (minibuffer-depth) 0))) (standard-input t) (st= andard-output t) inhibit-redisplay (cursor-in-echo-area nil)) (unwind-prote= ct (save-excursion (save-window-excursion (with-no-warnings (setq unread-co= mmand-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-deb= ug 4 t) (when (eq (quote lambda) (car-safe ...)) (backtrace-debug 5 t))) (p= op-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-s= howing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when n= oninteractive (when (> (count-lines ... ...) debugger-batch-max-lines) (got= o-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let (...= ) (goto-char ...) (forward-line ...) (delete-region middlestart ...)) (inse= rt "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-e= macs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (m= essage "") (save-excursion (recursive-edit))))) (if (get-buffer-window debu= gger-buffer 0) (with-current-buffer debugger-buffer (with-selected-window (= get-buffer-window debugger-buffer 0) (when (and (window-dedicated-p ...) (n= ot debugger-will-be-back)) (bury-buffer)))) (unless debugger-previous-state= (kill-buffer debugger-buffer))) (when (buffer-live-p debugger-buffer) (wit= h-current-buffer debugger-buffer (let ((inhibit-read-only t)) (erase-buffer= ) (if (null debugger-previous-state) (fundamental-mode) (insert (nth 1 debu= gger-previous-state)) (funcall (nth 0 debugger-previous-state)))))) (with-t= imeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger-ou= ter-match-data))) (let (debugger-value (debug-on-error nil) (debug-on-quit nil) (debugger-p= revious-state (if (get-buffer "*Backtrace*") (with-current-buffer (get-buff= er "*Backtrace*") (list major-mode (buffer-string))))) (debugger-buffer (ge= t-buffer-create "*Backtrace*")) (debugger-old-buffer (current-buffer)) (deb= ugger-step-after-exit nil) (debugger-will-be-back nil) (executing-kbd-macro= nil) (debugger-outer-match-data (match-data)) (debugger-outer-load-read-fu= nction load-read-function) (debugger-outer-overriding-local-map overriding-= local-map) (debugger-outer-overriding-terminal-local-map overriding-termina= l-local-map) (debugger-outer-track-mouse track-mouse) (debugger-outer-last-= command last-command) (debugger-outer-this-command this-command) (debugger-= outer-unread-command-char (with-no-warnings unread-command-char)) (debugger= -outer-unread-command-events unread-command-events) (debugger-outer-unread-= post-input-method-events unread-post-input-method-events) (debugger-outer-l= ast-input-event last-input-event) (debugger-outer-last-command-event last-c= ommand-event) (debugger-outer-last-nonmenu-event last-nonmenu-event) (debug= ger-outer-last-event-frame last-event-frame) (debugger-outer-standard-input= standard-input) (debugger-outer-standard-output standard-output) (debugger= -outer-inhibit-redisplay inhibit-redisplay) (debugger-outer-cursor-in-echo-= area cursor-in-echo-area) (debugger-with-timeout-suspend (with-timeout-susp= end))) (setq overriding-terminal-local-map nil) (let ((last-command nil) th= is-command track-mouse (inhibit-trace t) (inhibit-debug-on-entry t) unread-= command-events unread-post-input-method-events last-input-event last-comman= d-event last-nonmenu-event last-event-frame overriding-local-map load-read-= function (enable-recursive-minibuffers (or enable-recursive-minibuffers (> = (minibuffer-depth) 0))) (standard-input t) (standard-output t) inhibit-redi= splay (cursor-in-echo-area nil)) (unwind-protect (save-excursion (save-wind= ow-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (ca= r debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq ... ...) (b= acktrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote (...))) (debugg= er-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (= > ... debugger-batch-max-lines) (goto-char ...) (forward-line ...) (let ...= ... ... ...) (insert "...\n")) (goto-char (point-min)) (message "%s" (buff= er-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buff= er-read-only t)) (message "") (save-excursion (recursive-edit))))) (if (get= -buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (wit= h-selected-window (get-buffer-window debugger-buffer 0) (when (and ... ...)= (bury-buffer)))) (unless debugger-previous-state (kill-buffer debugger-buf= fer))) (when (buffer-live-p debugger-buffer) (with-current-buffer debugger-= buffer (let ((inhibit-read-only t)) (erase-buffer) (if (null debugger-previ= ous-state) (fundamental-mode) (insert ...) (funcall ...))))) (with-timeout-= unsuspend debugger-with-timeout-suspend) (set-match-data debugger-outer-mat= ch-data))) (setq load-read-function debugger-outer-load-read-function) (set= q overriding-local-map debugger-outer-overriding-local-map) (setq overridin= g-terminal-local-map debugger-outer-overriding-terminal-local-map) (setq tr= ack-mouse debugger-outer-track-mouse) (setq last-command debugger-outer-las= t-command) (setq this-command debugger-outer-this-command) (with-no-warning= s (setq unread-command-char debugger-outer-unread-command-char)) (setq unre= ad-command-events debugger-outer-unread-command-events) (setq unread-post-i= nput-method-events debugger-outer-unread-post-input-method-events) (setq la= st-input-event debugger-outer-last-input-event) (setq last-command-event de= bugger-outer-last-command-event) (setq last-nonmenu-event debugger-outer-la= st-nonmenu-event) (setq last-event-frame debugger-outer-last-event-frame) (= setq standard-input debugger-outer-standard-input) (setq standard-output de= bugger-outer-standard-output) (setq inhibit-redisplay debugger-outer-inhibi= t-redisplay) (setq cursor-in-echo-area debugger-outer-cursor-in-echo-area) = (setq debug-on-next-call debugger-step-after-exit) debugger-value) (if inhibit-redisplay debugger-value (unless noninteractive (message "Ent= ering debugger...")) (let (debugger-value (debug-on-error nil) (debug-on-qu= it nil) (debugger-previous-state (if (get-buffer "*Backtrace*") (with-curre= nt-buffer (get-buffer "*Backtrace*") (list major-mode (buffer-string))))) (= debugger-buffer (get-buffer-create "*Backtrace*")) (debugger-old-buffer (cu= rrent-buffer)) (debugger-step-after-exit nil) (debugger-will-be-back nil) (= executing-kbd-macro nil) (debugger-outer-match-data (match-data)) (debugger= -outer-load-read-function load-read-function) (debugger-outer-overriding-lo= cal-map overriding-local-map) (debugger-outer-overriding-terminal-local-map= overriding-terminal-local-map) (debugger-outer-track-mouse track-mouse) (d= ebugger-outer-last-command last-command) (debugger-outer-this-command this-= command) (debugger-outer-unread-command-char (with-no-warnings unread-comma= nd-char)) (debugger-outer-unread-command-events unread-command-events) (deb= ugger-outer-unread-post-input-method-events unread-post-input-method-events= ) (debugger-outer-last-input-event last-input-event) (debugger-outer-last-c= ommand-event last-command-event) (debugger-outer-last-nonmenu-event last-no= nmenu-event) (debugger-outer-last-event-frame last-event-frame) (debugger-o= uter-standard-input standard-input) (debugger-outer-standard-output standar= d-output) (debugger-outer-inhibit-redisplay inhibit-redisplay) (debugger-ou= ter-cursor-in-echo-area cursor-in-echo-area) (debugger-with-timeout-suspend= (with-timeout-suspend))) (setq overriding-terminal-local-map nil) (let ((l= ast-command nil) this-command track-mouse (inhibit-trace t) (inhibit-debug-= on-entry t) unread-command-events unread-post-input-method-events last-inpu= t-event last-command-event last-nonmenu-event last-event-frame overriding-l= ocal-map load-read-function (enable-recursive-minibuffers (or enable-recurs= ive-minibuffers (> (minibuffer-depth) 0))) (standard-input t) (standard-out= put t) inhibit-redisplay (cursor-in-echo-area nil)) (unwind-protect (save-e= xcursion (save-window-excursion (with-no-warnings (setq unread-command-char= -1)) (when (eq ... ...) (backtrace-debug 4 t) (when ... ...)) (pop-to-buff= er debugger-buffer (quote ...)) (debugger-mode) (debugger-setup-buffer debu= gger-args) (when noninteractive (when ... ... ... ... ...) (goto-char ...) = (message "%s" ...) (kill-emacs -1)) (message "") (let (... ...) (message ""= ) (save-excursion ...)))) (if (get-buffer-window debugger-buffer 0) (with-c= urrent-buffer debugger-buffer (with-selected-window (get-buffer-window debu= gger-buffer 0) (when ... ...))) (unless debugger-previous-state (kill-buffe= r debugger-buffer))) (when (buffer-live-p debugger-buffer) (with-current-bu= ffer debugger-buffer (let (...) (erase-buffer) (if ... ... ... ...)))) (wit= h-timeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger= -outer-match-data))) (setq load-read-function debugger-outer-load-read-func= tion) (setq overriding-local-map debugger-outer-overriding-local-map) (setq= overriding-terminal-local-map debugger-outer-overriding-terminal-local-map= ) (setq track-mouse debugger-outer-track-mouse) (setq last-command debugger= -outer-last-command) (setq this-command debugger-outer-this-command) (with-= no-warnings (setq unread-command-char debugger-outer-unread-command-char)) = (setq unread-command-events debugger-outer-unread-command-events) (setq unr= ead-post-input-method-events debugger-outer-unread-post-input-method-events= ) (setq last-input-event debugger-outer-last-input-event) (setq last-comman= d-event debugger-outer-last-command-event) (setq last-nonmenu-event debugge= r-outer-last-nonmenu-event) (setq last-event-frame debugger-outer-last-even= t-frame) (setq standard-input debugger-outer-standard-input) (setq standard= -output debugger-outer-standard-output) (setq inhibit-redisplay debugger-ou= ter-inhibit-redisplay) (setq cursor-in-echo-area debugger-outer-cursor-in-e= cho-area) (setq debug-on-next-call debugger-step-after-exit) debugger-value= )) debug(debug) implement-debug-on-entry() dired("~/" nil) call-interactively(dired nil nil) If I hit d, emacs crashs. This is the gdb backtrace: (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #2 0x08139d78 in abort () at emacs.c:394 #3 0x0819441e in mark_object (arg=3D139036542) at alloc.c:5706 #4 0x081944d1 in mark_object (arg=3D139036318) at alloc.c:5702 #5 0x08194363 in mark_object (arg=3D145795178) at alloc.c:5592 #6 0x081944d1 in mark_object (arg=3D139173742) at alloc.c:5702 #7 0x081944d1 in mark_object (arg=3D139036606) at alloc.c:5702 #8 0x08194363 in mark_object (arg=3D145795154) at alloc.c:5592 #9 0x081944d1 in mark_object (arg=3D139036622) at alloc.c:5702 #10 0x081944d1 in mark_object (arg=3D139279422) at alloc.c:5702 #11 0x081944d1 in mark_object (arg=3D139279374) at alloc.c:5702 #12 0x08194363 in mark_object (arg=3D139220250) at alloc.c:5592 #13 0x081944d1 in mark_object (arg=3D142104630) at alloc.c:5702 #14 0x081944d1 in mark_object (arg=3D142085174) at alloc.c:5702 #15 0x08194515 in mark_object (arg=3D142042046) at alloc.c:5595 #16 0x081944d1 in mark_object (arg=3D142011406) at alloc.c:5702 #17 0x08194515 in mark_object (arg=3D141221730) at alloc.c:5595 #18 0x08194bb7 in mark_vectorlike (ptr=3D0x8a3f9a0) at alloc.c:5391 #19 0x08194358 in mark_object (arg=3D141644778) at alloc.c:5591 #20 0x081944d1 in mark_object (arg=3D142034150) at alloc.c:5702 #21 0x081944d1 in mark_object (arg=3D139533566) at alloc.c:5702 #22 0x08194358 in mark_object (arg=3D139533582) at alloc.c:5591 #23 0x081944d1 in mark_object (arg=3D139402182) at alloc.c:5702 #24 0x081944d1 in mark_object (arg=3D141998270) at alloc.c:5702 #25 0x081944d1 in mark_object (arg=3D141998582) at alloc.c:5702 #26 0x08194515 in mark_object (arg=3D142178478) at alloc.c:5595 #27 0x081944d1 in mark_object (arg=3D142178566) at alloc.c:5702 #28 0x08194515 in mark_object (arg=3D145874074) at alloc.c:5595 #29 0x08194bb7 in mark_vectorlike (ptr=3D0x8b18ce8) at alloc.c:5391 #30 0x08194358 in mark_object (arg=3D142724330) at alloc.c:5591 #31 0x08194bb7 in mark_vectorlike (ptr=3D0x8a3dad0) at alloc.c:5391 #32 0x08194358 in mark_object (arg=3D145858138) at alloc.c:5591 #33 0x08194bb7 in mark_vectorlike (ptr=3D0x8474578) at alloc.c:5391 #34 0x08194bb7 in mark_vectorlike (ptr=3D0x8687508) at alloc.c:5391 #35 0x08194515 in mark_object (arg=3D145874002) at alloc.c:5595 #36 0x08194bb7 in mark_vectorlike (ptr=3D0x8b18c08) at alloc.c:5391 #37 0x08194358 in mark_object (arg=3D145858378) at alloc.c:5591 #38 0x08194bb7 in mark_vectorlike (ptr=3D0x8a449c8) at alloc.c:5391 #39 0x08194358 in mark_object (arg=3D141370674) at alloc.c:5591 #40 0x08194bb7 in mark_vectorlike (ptr=3D0x8a39a70) at alloc.c:5391 #41 0x08194358 in mark_object (arg=3D142741266) at alloc.c:5591 #42 0x08194bb7 in mark_vectorlike (ptr=3D0x8b1fc58) at alloc.c:5391 #43 0x08194358 in mark_object (arg=3D139743194) at alloc.c:5591 #44 0x081944d1 in mark_object (arg=3D139419246) at alloc.c:5702 #45 0x081944d1 in mark_object (arg=3D139423270) at alloc.c:5702 #46 0x081944d1 in mark_object (arg=3D139423254) at alloc.c:5702 #47 0x08194363 in mark_object (arg=3D139076430) at alloc.c:5592 #48 0x08194515 in mark_object (arg=3D141375194) at alloc.c:5595 #49 0x081944d1 in mark_object (arg=3D142206438) at alloc.c:5702 #50 0x081944d1 in mark_object (arg=3D142206382) at alloc.c:5702 #51 0x081944d1 in mark_object (arg=3D142221678) at alloc.c:5702 #52 0x08194358 in mark_object (arg=3D139248374) at alloc.c:5591 #53 0x081944d1 in mark_object (arg=3D139291134) at alloc.c:5702 #54 0x08194358 in mark_object (arg=3D139209450) at alloc.c:5591 #55 0x08194b32 in mark_char_table (ptr=3D0x8490348) at alloc.c:5418 #56 0x08194b73 in mark_char_table (ptr=3D0x846dca8) at alloc.c:5415 #57 0x081944d1 in mark_object (arg=3D138826062) at alloc.c:5702 #58 0x08194515 in mark_object (arg=3D141221514) at alloc.c:5595 #59 0x08194bb7 in mark_vectorlike (ptr=3D0x8576368) at alloc.c:5391 #60 0x08194358 in mark_object (arg=3D139907954) at alloc.c:5591 #61 0x08194bb7 in mark_vectorlike (ptr=3D0x8a3fbc0) at alloc.c:5391 #62 0x08194358 in mark_object (arg=3D142383258) at alloc.c:5591 #63 0x081944d1 in mark_object (arg=3D141985334) at alloc.c:5702 #64 0x081944d1 in mark_object (arg=3D141985846) at alloc.c:5702 #65 0x081944d1 in mark_object (arg=3D141983494) at alloc.c:5702 #66 0x081944d1 in mark_object (arg=3D141982494) at alloc.c:5702 #67 0x081944d1 in mark_object (arg=3D142004046) at alloc.c:5702 #68 0x081944d1 in mark_object (arg=3D142004830) at alloc.c:5702 #69 0x08194515 in mark_object (arg=3D138899458) at alloc.c:5595 #70 0x08194bb7 in mark_vectorlike (ptr=3D0x8b1bc58) at alloc.c:5391 #71 0x08194358 in mark_object (arg=3D138899506) at alloc.c:5591 #72 0x08194bb7 in mark_vectorlike (ptr=3D0x8663448) at alloc.c:5391 #73 0x08194358 in mark_object (arg=3D138898810) at alloc.c:5591 #74 0x08194bb7 in mark_vectorlike (ptr=3D0x8ae2038) at alloc.c:5391 #75 0x081944d1 in mark_object (arg=3D139792686) at alloc.c:5702 #76 0x081944a1 in mark_object (arg=3D145629373) at alloc.c:5538 #77 0x08194358 in mark_object (arg=3D145857562) at alloc.c:5591 #78 0x08194bb7 in mark_vectorlike (ptr=3D0x857b058) at alloc.c:5391 #79 0x08194358 in mark_object (arg=3D139199954) at alloc.c:5591 #80 0x081944d1 in mark_object (arg=3D139789422) at alloc.c:5702 #81 0x081944d1 in mark_object (arg=3D139789406) at alloc.c:5702 #82 0x08194515 in mark_object (arg=3D139171558) at alloc.c:5595 #83 0x081944d1 in mark_object (arg=3D139170694) at alloc.c:5702 #84 0x081944d1 in mark_object (arg=3D139038830) at alloc.c:5702 #85 0x08194363 in mark_object (arg=3D139891002) at alloc.c:5592 #86 0x081944d1 in mark_object (arg=3D142059206) at alloc.c:5702 #87 0x081944d1 in mark_object (arg=3D142078702) at alloc.c:5702 #88 0x08194515 in mark_object (arg=3D142391666) at alloc.c:5595 #89 0x08194bb7 in mark_vectorlike (ptr=3D0x8b166e8) at alloc.c:5391 #90 0x08194358 in mark_object (arg=3D139631874) at alloc.c:5591 #91 0x081944d1 in mark_object (arg=3D139759566) at alloc.c:5702 #92 0x081944d1 in mark_object (arg=3D139300646) at alloc.c:5702 #93 0x08194363 in mark_object (arg=3D139316346) at alloc.c:5592 #94 0x081944d1 in mark_object (arg=3D139755950) at alloc.c:5702 #95 0x08194363 in mark_object (arg=3D142463418) at alloc.c:5592 #96 0x081944d1 in mark_object (arg=3D145746174) at alloc.c:5702 #97 0x08194bb7 in mark_vectorlike (ptr=3D0x86630f8) at alloc.c:5391 #98 0x081944d1 in mark_object (arg=3D139706910) at alloc.c:5702 #99 0x08194515 in mark_object (arg=3D142069646) at alloc.c:5595 #100 0x081944d1 in mark_object (arg=3D139707278) at alloc.c:5702 #101 0x081944d1 in mark_object (arg=3D139707342) at alloc.c:5702 #102 0x08194358 in mark_object (arg=3D142424706) at alloc.c:5591 #103 0x081944d1 in mark_object (arg=3D142088286) at alloc.c:5702 #104 0x081944d1 in mark_object (arg=3D142091542) at alloc.c:5702 #105 0x081944d1 in mark_object (arg=3D142091310) at alloc.c:5702 #106 0x08194515 in mark_object (arg=3D145794842) at alloc.c:5595 #107 0x08194bb7 in mark_vectorlike (ptr=3D0x8b1ad98) at alloc.c:5391 #108 0x08194358 in mark_object (arg=3D139317314) at alloc.c:5591 #109 0x08194bb7 in mark_vectorlike (ptr=3D0x8b02158) at alloc.c:5391 #110 0x08194358 in mark_object (arg=3D140128634) at alloc.c:5591 #111 0x08194bb7 in mark_vectorlike (ptr=3D0x8b02288) at alloc.c:5391 #112 0x08194358 in mark_object (arg=3D141073730) at alloc.c:5591 #113 0x08194b32 in mark_char_table (ptr=3D0x8adbdc8) at alloc.c:5418 #114 0x08194b73 in mark_char_table (ptr=3D0x881d278) at alloc.c:5415 #115 0x081944d1 in mark_object (arg=3D139422566) at alloc.c:5702 #116 0x08194515 in mark_object (arg=3D140007178) at alloc.c:5595 #117 0x08194bb7 in mark_vectorlike (ptr=3D0x87e5170) at alloc.c:5391 #118 0x08194358 in mark_object (arg=3D139390306) at alloc.c:5591 #119 0x081944d1 in mark_object (arg=3D142048814) at alloc.c:5702 #120 0x08194515 in mark_object (arg=3D142242466) at alloc.c:5595 #121 0x081944d1 in mark_object (arg=3D139381926) at alloc.c:5702 #122 0x081944d1 in mark_object (arg=3D139382614) at alloc.c:5702 #123 0x08194358 in mark_object (arg=3D142384978) at alloc.c:5591 #124 0x081944d1 in mark_object (arg=3D142008078) at alloc.c:5702 #125 0x081944d1 in mark_object (arg=3D142008374) at alloc.c:5702 #126 0x08194515 in mark_object (arg=3D145857610) at alloc.c:5595 #127 0x08194bb7 in mark_vectorlike (ptr=3D0x86693a8) at alloc.c:5391 #128 0x08194358 in mark_object (arg=3D139576830) at alloc.c:5591 #129 0x081944d1 in mark_object (arg=3D139048462) at alloc.c:5702 #130 0x08194363 in mark_object (arg=3D138862962) at alloc.c:5592 #131 0x081944d1 in mark_object (arg=3D139165646) at alloc.c:5702 #132 0x081944d1 in mark_object (arg=3D139165814) at alloc.c:5702 #133 0x081944d1 in mark_object (arg=3D139165878) at alloc.c:5702 #134 0x08194515 in mark_object (arg=3D139592874) at alloc.c:5595 #135 0x081944d1 in mark_object (arg=3D139246046) at alloc.c:5702 #136 0x08194515 in mark_object (arg=3D142441346) at alloc.c:5595 #137 0x081944d1 in mark_object (arg=3D142122510) at alloc.c:5702 #138 0x08194515 in mark_object (arg=3D142441226) at alloc.c:5595 #139 0x081944d1 in mark_object (arg=3D142121390) at alloc.c:5702 #140 0x081944d1 in mark_object (arg=3D139280198) at alloc.c:5702 #141 0x081944d1 in mark_object (arg=3D139280142) at alloc.c:5702 #142 0x08194363 in mark_object (arg=3D141375026) at alloc.c:5592 #143 0x08194bb7 in mark_vectorlike (ptr=3D0x8688600) at alloc.c:5391 #144 0x08194358 in mark_object (arg=3D141331954) at alloc.c:5591 #145 0x08194bb7 in mark_vectorlike (ptr=3D0x8477490) at alloc.c:5391 #146 0x08194358 in mark_object (arg=3D141103034) at alloc.c:5591 #147 0x08194b32 in mark_char_table (ptr=3D0x8696e90) at alloc.c:5418 #148 0x08194b73 in mark_char_table (ptr=3D0x8a3d300) at alloc.c:5415 #149 0x081944d1 in mark_object (arg=3D142203630) at alloc.c:5702 #150 0x08194515 in mark_object (arg=3D141331978) at alloc.c:5595 #151 0x08194bb7 in mark_vectorlike (ptr=3D0x868b000) at alloc.c:5391 #152 0x08194358 in mark_object (arg=3D142151086) at alloc.c:5591 #153 0x08194859 in mark_object (arg=3D142379122) at alloc.c:5611 #154 0x081944d1 in mark_object (arg=3D139746694) at alloc.c:5702 #155 0x081944d1 in mark_object (arg=3D139746678) at alloc.c:5702 #156 0x08194975 in mark_buffer (buf=3D) at alloc.c:5762 #157 mark_object (arg=3D138859077) at alloc.c:5520 #158 0x0819484e in mark_object (arg=3D139281542) at alloc.c:5610 #159 0x081944d1 in mark_object (arg=3D139382870) at alloc.c:5702 #160 0x08194363 in mark_object (arg=3D139133042) at alloc.c:5592 #161 0x08194bb7 in mark_vectorlike (ptr=3D0x86ba970) at alloc.c:5391 #162 0x08194358 in mark_object (arg=3D141370914) at alloc.c:5591 #163 0x08194bb7 in mark_vectorlike (ptr=3D0x866e4f0) at alloc.c:5391 #164 0x08194358 in mark_object (arg=3D139304206) at alloc.c:5591 #165 0x08194515 in mark_object (arg=3D139090634) at alloc.c:5595 #166 0x081944d1 in mark_object (arg=3D139303702) at alloc.c:5702 #167 0x081944d1 in mark_object (arg=3D139063790) at alloc.c:5702 #168 0x081944d1 in mark_object (arg=3D139050518) at alloc.c:5702 #169 0x08194363 in mark_object (arg=3D139086778) at alloc.c:5592 #170 0x08194b32 in mark_char_table (ptr=3D0x848fc78) at alloc.c:5418 #171 0x08194b73 in mark_char_table (ptr=3D0x846df28) at alloc.c:5415 #172 0x081944d1 in mark_object (arg=3D138826094) at alloc.c:5702 #173 0x08194358 in mark_object (arg=3D139813946) at alloc.c:5591 #174 0x081944d1 in mark_object (arg=3D139239526) at alloc.c:5702 #175 0x081944d1 in mark_object (arg=3D139246566) at alloc.c:5702 #176 0x08194363 in mark_object (arg=3D139813922) at alloc.c:5592 #177 0x081944d1 in mark_object (arg=3D139279814) at alloc.c:5702 #178 0x08194363 in mark_object (arg=3D142249050) at alloc.c:5592 #179 0x08194bb7 in mark_vectorlike (ptr=3D0x86afc10) at alloc.c:5391 #180 0x08194515 in mark_object (arg=3D142440402) at alloc.c:5595 #181 0x081944d1 in mark_object (arg=3D142145142) at alloc.c:5702 #182 0x081944d1 in mark_object (arg=3D139424534) at alloc.c:5702 #183 0x08194363 in mark_object (arg=3D139373402) at alloc.c:5592 #184 0x08194bb7 in mark_vectorlike (ptr=3D0x8b163f0) at alloc.c:5391 #185 0x08194358 in mark_object (arg=3D139210106) at alloc.c:5591 #186 0x08194bb7 in mark_vectorlike (ptr=3D0x8b1e850) at alloc.c:5391 #187 0x08194358 in mark_object (arg=3D139892794) at alloc.c:5591 #188 0x08194bb7 in mark_vectorlike (ptr=3D0x8a3d728) at alloc.c:5391 #189 0x08194358 in mark_object (arg=3D141103490) at alloc.c:5591 #190 0x08194bb7 in mark_vectorlike (ptr=3D0x8a3ddc0) at alloc.c:5391 #191 0x08194358 in mark_object (arg=3D145858162) at alloc.c:5591 #192 0x081944d1 in mark_object (arg=3D142104846) at alloc.c:5702 #193 0x081944d1 in mark_object (arg=3D142132110) at alloc.c:5702 #194 0x081944d1 in mark_object (arg=3D142035670) at alloc.c:5702 #195 0x08194515 in mark_object (arg=3D145858066) at alloc.c:5595 #196 0x08194bb7 in mark_vectorlike (ptr=3D0x8b2aa40) at alloc.c:5391 #197 0x08194358 in mark_object (arg=3D139219698) at alloc.c:5591 #198 0x08194bb7 in mark_vectorlike (ptr=3D0x8b2abf8) at alloc.c:5391 #199 0x08194358 in mark_object (arg=3D139892962) at alloc.c:5591 #200 0x081944d1 in mark_object (arg=3D139280550) at alloc.c:5702 #201 0x08194515 in mark_object (arg=3D138959538) at alloc.c:5595 #202 0x08194bb7 in mark_vectorlike (ptr=3D0x8a45918) at alloc.c:5391 #203 0x08194358 in mark_object (arg=3D142158054) at alloc.c:5591 #204 0x08194363 in mark_object (arg=3D142157838) at alloc.c:5592 #205 0x08194363 in mark_object (arg=3D139802962) at alloc.c:5592 #206 0x08194bb7 in mark_vectorlike (ptr=3D0x881d020) at alloc.c:5391 #207 0x08194358 in mark_object (arg=3D142724138) at alloc.c:5591 #208 0x081944d1 in mark_object (arg=3D142130574) at alloc.c:5702 #209 0x08194363 in mark_object (arg=3D142130558) at alloc.c:5592 #210 0x08194363 in mark_object (arg=3D139856842) at alloc.c:5592 #211 0x08194358 in mark_object (arg=3D139341802) at alloc.c:5591 #212 0x081944d1 in mark_object (arg=3D139236190) at alloc.c:5702 #213 0x081944d1 in mark_object (arg=3D139304134) at alloc.c:5702 #214 0x081944d1 in mark_object (arg=3D139158982) at alloc.c:5702 #215 0x08194363 in mark_object (arg=3D138915594) at alloc.c:5592 #216 0x081944d1 in mark_object (arg=3D139158902) at alloc.c:5702 #217 0x081944d1 in mark_object (arg=3D139173838) at alloc.c:5702 #218 0x081944d1 in mark_object (arg=3D139036718) at alloc.c:5702 #219 0x08194515 in mark_object (arg=3D139342402) at alloc.c:5595 #220 0x081944d1 in mark_object (arg=3D139301334) at alloc.c:5702 #221 0x081944d1 in mark_object (arg=3D139301286) at alloc.c:5702 #222 0x08194363 in mark_object (arg=3D139543494) at alloc.c:5592 #223 0x081944d1 in mark_object (arg=3D139542366) at alloc.c:5702 #224 0x081944d1 in mark_object (arg=3D139484606) at alloc.c:5702 #225 0x08194363 in mark_object (arg=3D139049038) at alloc.c:5592 #226 0x08194363 in mark_object (arg=3D139574558) at alloc.c:5592 #227 0x08194363 in mark_object (arg=3D139574494) at alloc.c:5592 #228 0x081944d1 in mark_object (arg=3D139049462) at alloc.c:5702 #229 0x08194363 in mark_object (arg=3D138862914) at alloc.c:5592 #230 0x081944d1 in mark_object (arg=3D139037230) at alloc.c:5702 #231 0x081944d1 in mark_object (arg=3D139037214) at alloc.c:5702 #232 0x08194363 in mark_object (arg=3D139513306) at alloc.c:5592 #233 0x08194b32 in mark_char_table (ptr=3D0x848ffe0) at alloc.c:5418 #234 0x08194b73 in mark_char_table (ptr=3D0x846dde8) at alloc.c:5415 #235 0x081944d1 in mark_object (arg=3D138826078) at alloc.c:5702 #236 0x08194515 in mark_object (arg=3D138871842) at alloc.c:5595 #237 0x081944d1 in mark_object (arg=3D142081110) at alloc.c:5702 #238 0x08194363 in mark_object (arg=3D142433946) at alloc.c:5592 #239 0x081944d1 in mark_object (arg=3D142111662) at alloc.c:5702 #240 0x081944d1 in mark_object (arg=3D142111574) at alloc.c:5702 #241 0x08194363 in mark_object (arg=3D139446734) at alloc.c:5592 #242 0x081944d1 in mark_object (arg=3D139446742) at alloc.c:5702 #243 0x081944d1 in mark_object (arg=3D139446574) at alloc.c:5702 #244 0x08194363 in mark_object (arg=3D142189014) at alloc.c:5592 #245 0x081944d1 in mark_object (arg=3D142188998) at alloc.c:5702 #246 0x08194363 in mark_object (arg=3D139203514) at alloc.c:5592 #247 0x081944d1 in mark_object (arg=3D139240590) at alloc.c:5702 #248 0x081944d1 in mark_object (arg=3D139301102) at alloc.c:5702 #249 0x08194363 in mark_object (arg=3D139038926) at alloc.c:5592 #250 0x081944d1 in mark_object (arg=3D139039046) at alloc.c:5702 #251 0x08194515 in mark_object (arg=3D139802986) at alloc.c:5595 #252 0x081944d1 in mark_object (arg=3D142151486) at alloc.c:5702 #253 0x081f668f in traverse_intervals_noorder (tree=3D0x858e8c8, function= =3D0x8194bd0 ,=20 arg=3D138839322) at intervals.c:211 #254 0x0819184d in mark_interval_tree (tree=3D) at alloc.c:1= 552 #255 0x081949a2 in mark_buffer (buf=3D) at alloc.c:5739 #256 mark_object (arg=3D145858821) at alloc.c:5520 #257 0x0819484e in mark_object (arg=3D139198210) at alloc.c:5610 #258 0x081944d1 in mark_object (arg=3D139172230) at alloc.c:5702 #259 0x08194975 in mark_buffer (buf=3D) at alloc.c:5762 #260 mark_object (arg=3D144909237) at alloc.c:5520 #261 0x0819484e in mark_object (arg=3D138917834) at alloc.c:5610 #262 0x081944d1 in mark_object (arg=3D139486454) at alloc.c:5702 #263 0x081944d1 in mark_object (arg=3D139486438) at alloc.c:5702 #264 0x08194975 in mark_buffer (buf=3D) at alloc.c:5762 #265 mark_object (arg=3D139007421) at alloc.c:5520 #266 0x0819484e in mark_object (arg=3D139102682) at alloc.c:5610 #267 0x081944d1 in mark_object (arg=3D139838422) at alloc.c:5702 #268 0x08194363 in mark_object (arg=3D142384490) at alloc.c:5592 #269 0x081944d1 in mark_object (arg=3D142056454) at alloc.c:5702 #270 0x081944d1 in mark_object (arg=3D139162518) at alloc.c:5702 #271 0x08194363 in mark_object (arg=3D138860410) at alloc.c:5592 #272 0x081944d1 in mark_object (arg=3D142135822) at alloc.c:5702 #273 0x081944a1 in mark_object (arg=3D144984461) at alloc.c:5538 #274 0x08194358 in mark_object (arg=3D145858354) at alloc.c:5591 #275 0x08194bb7 in mark_vectorlike (ptr=3D0x8466d38) at alloc.c:5391 #276 0x08194d84 in Fgarbage_collect () at alloc.c:5099 #277 0x081ab536 in eval_sub (form=3D139285542) at eval.c:2239 #278 0x081ae303 in Feval (form=3D139285542, lexical=3D138839322) at eval.c:= 2198 #279 0x0813d1a9 in top_level_2 () at keyboard.c:1168 #280 0x081aa83d in internal_condition_case (bfun=3D0x813d190 ,= handlers=3D138870354,=20 hfun=3D0x813ec10 ) at eval.c:1509 #281 0x0813d9a5 in top_level_1 (ignore=3D138839322) at keyboard.c:1176 #282 0x081aa759 in internal_catch (tag=3D138868330, func=3D0x813d940 , arg=3D138839322) at eval.c:1266 #283 0x0813e72c in command_loop () at keyboard.c:1131 #284 recursive_edit_1 () at keyboard.c:758 #285 0x0813ea3e in Frecursive_edit () at keyboard.c:822 #286 0x080598c0 in main (argc=3D4, argv=3DCannot access memory at address 0= xa ) at emacs.c:1715 --=-=-=-- From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Feb 2012 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.1330505279543 (code B ref 8789); Wed, 29 Feb 2012 08:48:02 +0000 Received: (at 8789) by debbugs.gnu.org; 29 Feb 2012 08:47:59 +0000 Received: from localhost ([127.0.0.1]:55095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S2fCX-00008V-Im for submit@debbugs.gnu.org; Wed, 29 Feb 2012 03:47:58 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:49963) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1S2fC9-00007s-Rx for 8789@debbugs.gnu.org; Wed, 29 Feb 2012 03:47:45 -0500 Received: (qmail invoked by alias); 29 Feb 2012 08:47:14 -0000 Received: from 62-47-38-61.adsl.highway.telekom.at (EHLO [62.47.38.61]) [62.47.38.61] by mail.gmx.net (mp001) with SMTP; 29 Feb 2012 09:47:14 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/XaApDmQrXRFwxYZjLMrKpouK0Xcc6CYJKlrWU66 /LWny37zTOKqh0 Message-ID: <4F4DE60C.7010900@gmx.at> Date: Wed, 29 Feb 2012 09:47:08 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <4F47DA33.5070804@gmx.at> <86r4xev7fv.fsf@web.de> In-Reply-To: <86r4xev7fv.fsf@web.de> Content-Type: multipart/mixed; boundary="------------020005000306090107050509" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------020005000306090107050509 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit > Here it comes, produced today with "GNU Emacs 24.0.93.1 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-22 on zelenka, > modified by Debian". Thank you. Is it true that you can reproduce this with the given recipe at will? The combination of > Content of *Backtrace* before the crash: > > * (set-window-configuration wconfig) and > (gdb) bt > #0 0xb7fe2424 in __kernel_vsyscall () > #1 0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 > #2 0x08139d78 in abort () at emacs.c:394 > #3 0x0819441e in mark_object (arg=139036542) at alloc.c:5706 seems to indicate a collector problem when recovering from a window excursion. Reproducing a collector crash, however, is usually very difficult. Meanwhile please try the patch attached to check whether it (1) solves the original problem and (2) results in this crash as well. Thanks, martin --------------020005000306090107050509 Content-Type: text/plain; name="record_window_buffer.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="record_window_buffer.diff" === modified file 'lisp/emacs-lisp/debug.el' --- lisp/emacs-lisp/debug.el 2012-01-19 07:21:25 +0000 +++ lisp/emacs-lisp/debug.el 2012-02-26 18:55:02 +0000 @@ -194,7 +194,8 @@ ;; Place an extra debug-on-exit for macro's. (when (eq 'lambda (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) - (pop-to-buffer debugger-buffer) + (pop-to-buffer + debugger-buffer '((display-buffer-reuse-window display-buffer-in-previous-window) . nil)) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive @@ -245,7 +246,8 @@ ;; best to do that. (bury-buffer)))) (unless debugger-previous-state - (kill-buffer debugger-buffer))) + ;; (kill-buffer debugger-buffer) + )) ;; Restore the previous state of the debugger-buffer, in case we were ;; in a recursive invocation of the debugger. (when (buffer-live-p debugger-buffer) === modified file 'lisp/window.el' --- lisp/window.el 2012-02-12 05:10:30 +0000 +++ lisp/window.el 2012-02-26 19:09:54 +0000 @@ -2482,69 +2482,6 @@ ;;; Windows and buffers. -;; `prev-buffers' and `next-buffers' are two reserved window slots used -;; for (1) determining which buffer to show in the window when its -;; buffer shall be buried or killed and (2) which buffer to show for -;; `switch-to-prev-buffer' and `switch-to-next-buffer'. - -;; `prev-buffers' consists of -;; triples. The entries on this list are ordered by the time their -;; buffer has been removed from the window, the most recently removed -;; buffer's entry being first. The window-start and window-point -;; components are `window-start' and `window-point' at the time the -;; buffer was removed from the window which implies that the entry must -;; be added when `set-window-buffer' removes the buffer from the window. - -;; `next-buffers' is the list of buffers that have been replaced -;; recently by `switch-to-prev-buffer'. These buffers are the least -;; preferred candidates of `switch-to-prev-buffer' and the preferred -;; candidates of `switch-to-next-buffer' to switch to. This list is -;; reset to nil by any action changing the window's buffer with the -;; exception of `switch-to-prev-buffer' and `switch-to-next-buffer'. -;; `switch-to-prev-buffer' pushes the buffer it just replaced on it, -;; `switch-to-next-buffer' pops the last pushed buffer from it. - -;; Both `prev-buffers' and `next-buffers' may reference killed buffers -;; if such a buffer was killed while the window was hidden within a -;; window configuration. Such killed buffers get removed whenever -;; `switch-to-prev-buffer' or `switch-to-next-buffer' encounter them. - -;; The following function is called by `set-window-buffer' _before_ it -;; replaces the buffer of the argument window with the new buffer. -(defun record-window-buffer (&optional window) - "Record WINDOW's buffer. -WINDOW must be a live window and defaults to the selected one." - (let* ((window (window-normalize-window window t)) - (buffer (window-buffer window)) - (entry (assq buffer (window-prev-buffers window)))) - ;; Reset WINDOW's next buffers. If needed, they are resurrected by - ;; `switch-to-prev-buffer' and `switch-to-next-buffer'. - (set-window-next-buffers window nil) - - (when entry - ;; Remove all entries for BUFFER from WINDOW's previous buffers. - (set-window-prev-buffers - window (assq-delete-all buffer (window-prev-buffers window)))) - - ;; Don't record insignificant buffers. - (unless (eq (aref (buffer-name buffer) 0) ?\s) - ;; Add an entry for buffer to WINDOW's previous buffers. - (with-current-buffer buffer - (let ((start (window-start window)) - (point (window-point-1 window))) - (setq entry - (cons buffer - (if entry - ;; We have an entry, update marker positions. - (list (set-marker (nth 1 entry) start) - (set-marker (nth 2 entry) point)) - ;; Make new markers. - (list (copy-marker start) - (copy-marker point))))) - - (set-window-prev-buffers - window (cons entry (window-prev-buffers window)))))))) - (defun unrecord-window-buffer (&optional window buffer) "Unrecord BUFFER in WINDOW. WINDOW must be a live window and defaults to the selected one. @@ -4846,6 +4783,50 @@ (and pop-up-windows (display-buffer-pop-up-window buffer alist)))) +(defun display-buffer-in-previous-window (buffer alist) + "Display BUFFER in a window previously showing it. +If ALIST has a non-nil `inhibit-same-window' entry, the selected +window is not eligible for reuse. + +If ALIST contains a `reusable-frames' entry, its value determines +which frames to search for a reusable window: + nil -- the selected frame (actually the last non-minibuffer frame) + A frame -- just that frame + `visible' -- all visible frames + 0 -- all frames on the current terminal + t -- all frames. + +If ALIST contains no `reusable-frames' entry, search just the +selected frame if `display-buffer-reuse-frames' and +`pop-up-frames' are both nil; search all frames on the current +terminal if either of those variables is non-nil." + (let* ((alist-entry (assq 'reusable-frames alist)) + (inhibit-same-window + (cdr (assq 'inhibit-same-window alist))) + (frames (cond + (alist-entry (cdr alist-entry)) + ((if (eq pop-up-frames 'graphic-only) + (display-graphic-p) + pop-up-frames) + 0) + (display-buffer-reuse-frames 0) + (t (last-nonminibuffer-frame)))) + best-window second-best-window window) + (when inhibit-same-window (ding)) + (catch 'best + (dolist (window (window-list-1 (frame-first-window) 'nomini frames)) + (when (and (assq buffer (window-prev-buffers window)) + (not (window-dedicated-p window))) + (if (eq window (selected-window)) + (unless inhibit-same-window + (setq second-best-window window)) + (setq best-window window) + (throw 'best t))))) + + (when (setq window (or best-window second-best-window)) + (display-buffer-record-window 'reuse window buffer) + (window--display-buffer-2 buffer window display-buffer-mark-dedicated)))) + (defun display-buffer-use-some-window (buffer alist) "Display BUFFER in an existing window. Search for a usable window, set that window to the buffer, and === modified file 'src/window.c' --- src/window.c 2012-02-23 17:40:33 +0000 +++ src/window.c 2012-02-27 07:43:06 +0000 @@ -51,7 +51,7 @@ #endif Lisp_Object Qwindowp, Qwindow_live_p; -static Lisp_Object Qwindow_configuration_p, Qrecord_window_buffer; +static Lisp_Object Qwindow_configuration_p; static Lisp_Object Qwindow_deletable_p, Qdelete_window, Qdisplay_buffer; static Lisp_Object Qreplace_buffer_in_windows, Qget_mru_window; static Lisp_Object Qwindow_resize_root_window, Qwindow_resize_root_window_vertically; @@ -1647,15 +1647,41 @@ DEFUN ("set-window-prev-buffers", Fset_window_prev_buffers, Sset_window_prev_buffers, 2, 2, 0, - doc: /* Set WINDOW's previous buffers to PREV-BUFFERS. + doc: /* Set WINDOW's previous buffers to PREV-BUFFERS. WINDOW must be a live window and defaults to the selected one. PREV-BUFFERS should be a list of elements (BUFFER WINDOW-START POS), where BUFFER is a buffer, WINDOW-START is the start position of the window for that buffer, and POS is a window-specific point value. */) - (Lisp_Object window, Lisp_Object prev_buffers) + (Lisp_Object window, Lisp_Object prev_buffers) { - return decode_window (window)->prev_buffers = prev_buffers; + register struct window *w = decode_window (window); + + if (NILP (prev_buffers)) + return w->prev_buffers = Qnil; + else if (!CONSP (prev_buffers)) + return w->prev_buffers; + else + { + /* Run cycle detection on prev_buffers. */ + Lisp_Object tortoise, hare; + + hare = tortoise = prev_buffers; + while (CONSP (hare)) + { + hare = XCDR (hare); + if (!CONSP (hare)) + break; + + hare = XCDR (hare); + tortoise = XCDR (tortoise); + + if (EQ (hare, tortoise)) + return w->prev_buffers; + } + + return w->prev_buffers = prev_buffers; + } } DEFUN ("window-next-buffers", Fwindow_next_buffers, Swindow_next_buffers, @@ -1674,7 +1700,33 @@ NEXT-BUFFERS should be a list of buffers. */) (Lisp_Object window, Lisp_Object next_buffers) { - return decode_window (window)->next_buffers = next_buffers; + register struct window *w = decode_window (window); + + if (NILP (next_buffers)) + return w->next_buffers = Qnil; + else if (!CONSP (next_buffers)) + return w->next_buffers; + else + { + /* Run cycle detection on next_buffers. */ + Lisp_Object tortoise, hare; + + hare = tortoise = next_buffers; + while (CONSP (hare)) + { + hare = XCDR (hare); + if (!CONSP (hare)) + break; + + hare = XCDR (hare); + tortoise = XCDR (tortoise); + + if (EQ (hare, tortoise)) + return w->next_buffers; + } + + return w->next_buffers = next_buffers; + } } DEFUN ("window-parameters", Fwindow_parameters, Swindow_parameters, @@ -2940,13 +2992,94 @@ DEFUN ("run-window-configuration-change-hook", Frun_window_configuration_change_hook, Srun_window_configuration_change_hook, 1, 1, 0, doc: /* Run `window-configuration-change-hook' for FRAME. */) - (Lisp_Object frame) + (Lisp_Object frame) { CHECK_LIVE_FRAME (frame); run_window_configuration_change_hook (XFRAME (frame)); return Qnil; } +/* `prev_buffers' and `next_buffers' are two reserved window slots used +for determining + +(1) which buffer to show in the window when its buffer shall be buried + or killed, and + +(2) which buffer to show for `switch-to-prev-buffer' and + `switch-to-next-buffer'. + +`prev_buffers' is built from +triples. The entries on this list are ordered by the time their buffer +has been removed from the window, the most recently removed buffer's +entry being first. The window-start and window-point components are +`window-start' and `window-point' at the time the buffer was removed +from the window which implies that the entry must be added when +Fset_window_buffer removes the buffer from the window. + +`next_buffers' is the list of buffers that have been replaced recently +by `switch-to-prev-buffer'. These buffers are the least preferred +candidates of `switch-to-prev-buffer' and the preferred candidates of +`switch-to-next-buffer' to switch to. This list is reset to nil by any +action changing the window's buffer with the exception of +`switch-to-prev-buffer' and `switch-to-next-buffer'. +`switch-to-prev-buffer' pushes the buffer it just replaced on it, +`switch-to-next-buffer' pops the last pushed buffer from it. + +Both `prev_buffers' and `next_buffers' may reference killed buffers if +such a buffer was killed while the window was hidden within a window +configuration. Such killed buffers get removed whenever +`switch-to-prev-buffer' or `switch-to-next-buffer' encounter them. + +The following function must be called by Fset_window_buffer and +Fset_window_configuration _before_ these replace the buffer of the +argument window with the new buffer. */ + +static void +record_window_buffer (Lisp_Object window) +{ + struct window *w = XWINDOW (window); + Lisp_Object buffer = w->buffer; + struct buffer *b = XBUFFER (buffer); + Lisp_Object entry = Fassq (buffer, w->prev_buffers); + Lisp_Object start_marker, point_marker, point; + int count = SPECPDL_INDEX (); + + /* Return immediately if BUFFER is not a buffer. */ + if (!BUFFERP (buffer)) + return; + + /* Reset WINDOW's next buffers. If needed, they are resurrected by + `switch-to-prev-buffer' and `switch-to-next-buffer'. */ + w->next_buffers = Qnil; + + if (!NILP (entry)) + /* Remove all entries for BUFFER from WINDOW's previous buffers. */ + w->prev_buffers = Fdelq (entry, w->prev_buffers); + + if (NILP (BVAR (b, name)) || SREF (BVAR (b, name), 0) == ' ') + /* Don't record dead or insignificant buffers. */ + return; + + if (current_buffer != b) + { + /* Make sure Fpoint below gets the right buffer. */ + record_unwind_protect (set_buffer_if_live, Fcurrent_buffer ()); + set_buffer_internal (b); + } + + /* Reuse existing markers if possible. */ + start_marker = !NILP (entry) ? Fnth (make_number (1), entry) : Fmake_marker (); + point_marker = !NILP (entry) ? Fnth (make_number (2), entry) : Fmake_marker (); + point = EQ (window, selected_window) ? Fpoint () : w->pointm; + set_marker_restricted (start_marker, w->start, buffer); + set_marker_restricted (point_marker, point, buffer); + w->prev_buffers = Fcons (list3 (buffer, start_marker, point_marker), + w->prev_buffers); + + unbind_to (count, Qnil); +} + + /* Make WINDOW display BUFFER as its contents. RUN_HOOKS_P non-zero means it's allowed to run hooks. See make_frame for a case where it's not allowed. KEEP_MARGINS_P non-zero means that the current @@ -3094,7 +3227,7 @@ dedication. */ w->dedicated = Qnil; - call1 (Qrecord_window_buffer, window); + record_window_buffer (window); } unshow_buffer (w); @@ -5587,6 +5720,8 @@ else if (!NILP (BVAR (XBUFFER (p->buffer), name))) /* If saved buffer is alive, install it. */ { + if (!EQ (w->buffer, p->buffer)) + record_window_buffer (window); w->buffer = p->buffer; w->start_at_line_beg = p->start_at_line_beg; set_marker_restricted (w->start, p->start, w->buffer); @@ -5620,6 +5755,7 @@ && SCHARS (auto_buffer_name) != 0 && !NILP (w->buffer = Fget_buffer_create (auto_buffer_name))) { + record_window_buffer (window); set_marker_restricted (w->start, make_number (0), w->buffer); set_marker_restricted (w->pointm, make_number (0), w->buffer); w->start_at_line_beg = Qt; @@ -5627,6 +5763,7 @@ else /* Window has no live buffer, get one. */ { + record_window_buffer (window); /* Get the buffer via other_buffer_safely in order to avoid showing an unimportant buffer and, if necessary, to recreate *scratch* in the course (part of Juanma's bs-show @@ -6509,7 +6646,6 @@ DEFSYM (Qsafe, "safe"); DEFSYM (Qdisplay_buffer, "display-buffer"); DEFSYM (Qreplace_buffer_in_windows, "replace-buffer-in-windows"); - DEFSYM (Qrecord_window_buffer, "record-window-buffer"); DEFSYM (Qget_mru_window, "get-mru-window"); DEFSYM (Qtemp_buffer_show_hook, "temp-buffer-show-hook"); DEFSYM (Qabove, "above"); --------------020005000306090107050509-- From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Mar 2012 19:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.133080381122901 (code B ref 8789); Sat, 03 Mar 2012 19:44:02 +0000 Received: (at 8789) by debbugs.gnu.org; 3 Mar 2012 19:43:31 +0000 Received: from localhost ([127.0.0.1]:60295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S3ura-0005xA-Mt for submit@debbugs.gnu.org; Sat, 03 Mar 2012 14:43:31 -0500 Received: from fmmailgate06.web.de ([217.72.192.247]:58551) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S3urF-0005wN-9q for 8789@debbugs.gnu.org; Sat, 03 Mar 2012 14:43:19 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate06.web.de (Postfix) with ESMTP id D0766D9F99E for <8789@debbugs.gnu.org>; Sat, 3 Mar 2012 20:42:30 +0100 (CET) Received: from dragon.dragon ([80.226.24.3]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0MZDga-1RpYKL29To-00KysE; Sat, 03 Mar 2012 20:42:30 +0100 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <4F47DA33.5070804@gmx.at> <86r4xev7fv.fsf@web.de> <4F4DE60C.7010900@gmx.at> Date: Sat, 03 Mar 2012 20:48:30 +0100 In-Reply-To: <4F4DE60C.7010900@gmx.at> (martin rudalics's message of "Wed, 29 Feb 2012 09:47:08 +0100") Message-ID: <86hay5zcs1.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:rScfBM0wteAGtjLLn/aAj+cynrVd9+BcoHdDf5DSPLR QvirebjzNsAeKBXc+w1lnFOJ7TCwln+CKKMSxkv2puWgmndlC/ CwtzXe5+GIOWebq1Z7ZfytL4njzDnco/cUNM1bvU00n5buO9t9 iXGUGjjY3dT5wlvUw+8DgVKTiWtqCfrU1bqKurXquasIIeG11T DZQTdMU5WmV/7TpG+vwg1rDA134WAcsZKTAUabXyyk= X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) martin rudalics writes: > Is it true that you can reproduce this with the given recipe at will? > The combination of > > > Content of *Backtrace* before the crash: > > > > * (set-window-configuration wconfig) > > and > > > (gdb) bt > > #0 0xb7fe2424 in __kernel_vsyscall () > > #1 0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 > > #2 0x08139d78 in abort () at emacs.c:394 > > #3 0x0819441e in mark_object (arg=139036542) at alloc.c:5706 > > seems to indicate a collector problem when recovering from a window > excursion. Reproducing a collector crash, however, is usually very > difficult. Yes, I can reproduce it at will. I tried a few times again, and everytime the backtrace looked like this. > Meanwhile please try the patch attached to check whether it (1) solves > the original problem and (2) results in this crash as well. I'm afraid I can't do this, at least not at the moment. I can't build Emacs right now - I'm changing residence, having not much time and no relyable connection to the net. Maybe someone else can test it? Or is it appropriate to test the Elisp parts of your patch seperately? BTW, I can reproduce the crash on different Gnu/Linux systems, so it's likely that the crash can be reproduced on other computers as well. Michael From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Mar 2012 18:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13314914331527 (code B ref 8789); Sun, 11 Mar 2012 18:44:01 +0000 Received: (at 8789) by debbugs.gnu.org; 11 Mar 2012 18:43:53 +0000 Received: from localhost ([127.0.0.1]:45285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S6nkG-0000OZ-Dv for submit@debbugs.gnu.org; Sun, 11 Mar 2012 14:43:52 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:60066) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1S6nkC-0000OM-Sc for 8789@debbugs.gnu.org; Sun, 11 Mar 2012 14:43:50 -0400 Received: (qmail invoked by alias); 11 Mar 2012 18:14:01 -0000 Received: from 62-47-32-71.adsl.highway.telekom.at (EHLO [62.47.32.71]) [62.47.32.71] by mail.gmx.net (mp020) with SMTP; 11 Mar 2012 19:14:01 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/cHgRoHLXccrErTojN/yz5fe4m8FaHWZG/XB743u 1MXVMQJSwY/SaZ Message-ID: <4F5CEB93.7030609@gmx.at> Date: Sun, 11 Mar 2012 19:14:43 +0100 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> In-Reply-To: <4F3BE4CB.3030909@gmx.at> Content-Type: multipart/mixed; boundary="------------060105000307020400040009" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------060105000307020400040009 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit > > The general approach sounds good, but we should probably try to refine > > it so as to minimize changes in behavior, and so it works right in the > > multi-frame and even multi-terminal case. > > > > We could try to store the last-used-window in a variable > > `debugger-last-used-window' and use that window after checking that it's > > still live and is visible in the selected terminal. OK. Attached find my last ;-) stab at this. martin --------------060105000307020400040009 Content-Type: text/plain; name="debug.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="debug.el.diff" === modified file 'lisp/emacs-lisp/debug.el' --- lisp/emacs-lisp/debug.el 2012-01-19 07:21:25 +0000 +++ lisp/emacs-lisp/debug.el 2012-03-11 18:00:23 +0000 @@ -108,6 +108,25 @@ - exit: called because of exit of a flagged function. - error: called because of `debug-on-error'.") +(defvar debugger-buffer-last-window nil + "If non-nil, the last window displaying `debugger-buffer'") + +;; An appropriate substitute for this should be implemented in +;; window.el. +(defun debugger-buffer-use-last-window (buffer alist) + "Try displaying debugger buffer in last window where it was seen." + ;; Reuse only a window on the selected frame, excluding the selected + ;; and dedicated windows. + (when (and (window-live-p debugger-buffer-last-window) + (not (eq debugger-buffer-last-window (selected-window))) + (not (window-dedicated-p debugger-buffer-last-window)) + (eq (window-frame debugger-buffer-last-window) + (selected-frame))) + (display-buffer-record-window + 'reuse debugger-buffer-last-window buffer) + (window--display-buffer-2 + buffer debugger-buffer-last-window display-buffer-mark-dedicated))) + ;;;###autoload (setq debugger 'debug) ;;;###autoload @@ -194,7 +213,15 @@ ;; Place an extra debug-on-exit for macro's. (when (eq 'lambda (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) - (pop-to-buffer debugger-buffer) + + (pop-to-buffer + debugger-buffer + '((display-buffer-reuse-window + ;; Try reusing the last window where debugger-buffer + ;; was seen (Bug#8789). + debugger-buffer-use-last-window) . nil)) + (setq debugger-buffer-last-window (selected-window)) + (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive --------------060105000307020400040009-- From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Sep 2012 13:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: michael_heerdegen@web.de Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13471112213822 (code B ref 8789); Sat, 08 Sep 2012 13:34:01 +0000 Received: (at 8789) by debbugs.gnu.org; 8 Sep 2012 13:33:41 +0000 Received: from localhost ([127.0.0.1]:48026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TALAK-0000za-Q5 for submit@debbugs.gnu.org; Sat, 08 Sep 2012 09:33:41 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:43446) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TALAI-0000zS-7f for 8789@debbugs.gnu.org; Sat, 08 Sep 2012 09:33:39 -0400 Received: (qmail invoked by alias); 08 Sep 2012 13:33:13 -0000 Received: from 62-47-48-244.adsl.highway.telekom.at (EHLO [62.47.48.244]) [62.47.48.244] by mail.gmx.net (mp070) with SMTP; 08 Sep 2012 15:33:13 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18iI5IqjDIi53hmBDa2W1HNnzFq3Ub2hkPv8m+SPL 8gmH442+vugqQL Message-ID: <504B4940.9000809@gmx.at> Date: Sat, 08 Sep 2012 15:33:52 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> In-Reply-To: <877gzmqwcf.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) I now checked in a fix for this in revision 109937 on trunk. Please test it. Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Sep 2012 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13474596257701 (code B ref 8789); Wed, 12 Sep 2012 14:21:02 +0000 Received: (at 8789) by debbugs.gnu.org; 12 Sep 2012 14:20:25 +0000 Received: from localhost ([127.0.0.1]:57137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TBnnk-00020A-H6 for submit@debbugs.gnu.org; Wed, 12 Sep 2012 10:20:24 -0400 Received: from mout.web.de ([212.227.15.3]:56454) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TBnni-000202-Dr for 8789@debbugs.gnu.org; Wed, 12 Sep 2012 10:20:23 -0400 Received: from dragon.dragon ([94.216.142.196]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0M5Oct-1TT2Hw00zP-00z6JE; Wed, 12 Sep 2012 16:19:35 +0200 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> Date: Wed, 12 Sep 2012 16:20:36 +0200 In-Reply-To: <504B4940.9000809@gmx.at> (martin rudalics's message of "Sat, 08 Sep 2012 15:33:52 +0200") Message-ID: <86wqzznwzv.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:mtMDfDxi4IOX51JgH++2a+4JCwkSywyVibd4XgQfc2O BWa52YOpT9MxHIbVbJAwNpMptnAIe/wUwMOc563dtfOZmnSDTW BcQpSkGNGGDTl8Kr9xrvstqlldSzGZnbQl7WYD65yXKqlGO+a7 7Cy+uybTw6B89290B54lCdd/6yke7zA+QEhjt42GbIIi9qIT34 oeawXBiDhF4s4XwQq+K2NXyl0D0tIIIGMXSgaaQPio= X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.3 (--) martin rudalics writes: > I now checked in a fix for this in revision 109937 on trunk. > Please test it. Thanks so much for your work, Martin! After some quick tests with emacs -Q, as well as with my own setup, I must say that this works quite well now. No more "hopping" of the *Backtrace* buffer, and no crashes. So, your fix seems ok to me, but others may make some tests as well with their setups. Only one wish remains: it is not possible to resize the height of the window displaying the *Backtrace* buffer durably. When I resize it with the mouse in emacs -Q, this is undone when I hit d in the debugger. It would be cool if the size of the window could be changed durably. Regards, Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Sep 2012 15:52:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134746508715675 (code B ref 8789); Wed, 12 Sep 2012 15:52:03 +0000 Received: (at 8789) by debbugs.gnu.org; 12 Sep 2012 15:51:27 +0000 Received: from localhost ([127.0.0.1]:57256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TBpDq-00044m-IT for submit@debbugs.gnu.org; Wed, 12 Sep 2012 11:51:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:38488) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TBpDo-00044e-Cf for 8789@debbugs.gnu.org; Wed, 12 Sep 2012 11:51:25 -0400 Received: (qmail invoked by alias); 12 Sep 2012 15:50:36 -0000 Received: from 62-47-58-95.adsl.highway.telekom.at (EHLO [62.47.58.95]) [62.47.58.95] by mail.gmx.net (mp070) with SMTP; 12 Sep 2012 17:50:36 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/n/LEIm+jnSMgLzXZb3ZQLD3G/ELO1n2Tanj5vrw 40eNEq7pqWJ+9T Message-ID: <5050AF52.5020804@gmx.at> Date: Wed, 12 Sep 2012 17:50:42 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> In-Reply-To: <86wqzznwzv.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Only one wish remains: it is not possible to resize the height of the > window displaying the *Backtrace* buffer durably. When I resize it with > the mouse in emacs -Q, this is undone when I hit d in the debugger. It > would be cool if the size of the window could be changed durably. I committed a fix. Please try it. martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Sep 2012 20:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Michael Heerdegen'" , "'martin rudalics'" Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134791414129658 (code B ref 8789); Mon, 17 Sep 2012 20:36:02 +0000 Received: (at 8789) by debbugs.gnu.org; 17 Sep 2012 20:35:41 +0000 Received: from localhost ([127.0.0.1]:40363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDi2f-0007iI-7a for submit@debbugs.gnu.org; Mon, 17 Sep 2012 16:35:41 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:24626) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDi2c-0007iA-4h for 8789@debbugs.gnu.org; Mon, 17 Sep 2012 16:35:39 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8HKYJAR017198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Sep 2012 20:34:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8HKYI1p019326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2012 20:34:19 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8HKYI4J016975; Mon, 17 Sep 2012 15:34:18 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Sep 2012 13:34:18 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> Date: Mon, 17 Sep 2012 13:34:17 -0700 Message-ID: <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86wqzznwzv.fsf@web.de> Thread-Index: Ac2Q8cf3uJONCgkYSjuwJPhyFOkrOAEIBfMA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Importance: High X-Message-Flag: Follow up X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) I'm guessing, but I do not know for sure, that it is the change you made for this bug that has now broken the debugger for me. For me, *Backtrace* is a special-display buffer, so it is shown in its own, special-display frame. In this build, things are not broken (still OK): In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-09-02 on MARVIN Bzr revision: 109861 eggert@cs.ucla.edu-20120902171035-7mzihil3xd6bjfiy Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.6) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2' And in this build, things are broken: In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-09-17 on MARVIN Bzr revision: 110062 cyd@gnu.org-20120917054104-r93rtwkrtva73ewe Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-3.0.9/include -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2' What is broken is this: Before, the same frame (seemingly) existed throughout. I could hit `d' any number of times, and everything was smooth. I could expand the frame size or reposition it, and it stayed wherever I put it. Now, it appears that each time I hit `d' the frame is deleted and a new frame is created to replace it. And it is always re-created with the same, default size and position (top left of screen). This is horrible. Not only does the re-creation produce a tremendous blink/flash, but the repositioning and resizing back to the default position and size are intolerable. I cannot see anything useful in the buffer - I need to stretch the frame out again after each `d' to see anything wide. And I need to reposition the frame to the right (for example) after each `d', if I have another frame at the left that I want to continue to see (e.g. a frame showing the source code, or *Completions*). If you prefer this as a separate bug report, feel free to copy the above into a new bug - you have all of the info. This is with my own setup, which Martin is pretty familiar with: non-nil popup-frames etc. For me, this change is a horrible regression - makes the debugger unusable. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Sep 2012 22:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13479211519878 (code B ref 8789); Mon, 17 Sep 2012 22:33:02 +0000 Received: (at 8789) by debbugs.gnu.org; 17 Sep 2012 22:32:31 +0000 Received: from localhost ([127.0.0.1]:40449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDjri-0002ZD-Qx for submit@debbugs.gnu.org; Mon, 17 Sep 2012 18:32:31 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:33212) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TDjrf-0002Z2-Ud for 8789@debbugs.gnu.org; Mon, 17 Sep 2012 18:32:28 -0400 Received: (qmail invoked by alias); 17 Sep 2012 22:31:10 -0000 Received: from 62-47-47-244.adsl.highway.telekom.at (EHLO [62.47.47.244]) [62.47.47.244] by mail.gmx.net (mp037) with SMTP; 18 Sep 2012 00:31:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/h7ith5V7hOkgPyCYj5Sdw7nmUHcFe5AFHHS4X9J geAMXle6lc7Ynq Message-ID: <5057A4A3.4010100@gmx.at> Date: Tue, 18 Sep 2012 00:30:59 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> In-Reply-To: <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Before, the same frame (seemingly) existed throughout. I could hit `d' any > number of times, and everything was smooth. I could expand the frame size or > reposition it, and it stayed wherever I put it. > > Now, it appears that each time I hit `d' the frame is deleted and a new frame is > created to replace it. And it is always re-created with the same, default size > and position (top left of screen). Try customizing `debugger-bury-or-kill'. martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Sep 2012 22:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134792204511937 (code B ref 8789); Mon, 17 Sep 2012 22:48:01 +0000 Received: (at 8789) by debbugs.gnu.org; 17 Sep 2012 22:47:25 +0000 Received: from localhost ([127.0.0.1]:40459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDk68-00036T-KJ for submit@debbugs.gnu.org; Mon, 17 Sep 2012 18:47:24 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:23549) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDk66-00036J-5E for 8789@debbugs.gnu.org; Mon, 17 Sep 2012 18:47:23 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8HMk312003914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Sep 2012 22:46:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8HMk3Po023319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2012 22:46:03 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8HMk2TE029174; Mon, 17 Sep 2012 17:46:02 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Sep 2012 15:46:02 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> Date: Mon, 17 Sep 2012 15:46:00 -0700 Message-ID: <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5057A4A3.4010100@gmx.at> Thread-Index: Ac2VJCVBbi6PL5PtTmS6sG07MR50NQAAIzyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > Try customizing `debugger-bury-or-kill'. 1. OK, I was not aware of that option; thanks. Please document it. (I do not see it in either the Emacs manual or the Elisp manual.) 2. I tried each of the values listed in the doc string. None of them had any effect at all. Same broken behavior, always: the frame is deleted, then re-created with the default size and position (i.e., ignoring its previous size and position). That re-creation takes perhaps 0.5 sec or 1 sec, which means that it is visually quite distracting, besides the fact that the size and position prevent using the debugger efffectively (really, prevent using it at all). I am using the regular Emacs debugger, not `edebug'. E.g., I am using `debug-on-entry' etc. Dunno whether that is pertinent. The doc says nothing about `edebug', in any case. 3. Wrt the new option's defcustom: If the documented four possible values are the only possible values, then the defcustom should be rewritten so that the user can choose (and can only choose) by using the Value Menu. S?he should not have to or be allowed to enter a quoted symbol name in a text edit field. If the documented possible values are not the only possible values, then the doc string should be updated to mention what other possible values there are and what they do. This (#3) is a bug. Do you want me to file a separate bug report for it? From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Sep 2012 07:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134795234814674 (code B ref 8789); Tue, 18 Sep 2012 07:13:02 +0000 Received: (at 8789) by debbugs.gnu.org; 18 Sep 2012 07:12:28 +0000 Received: from localhost ([127.0.0.1]:40733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDryt-0003oZ-2q for submit@debbugs.gnu.org; Tue, 18 Sep 2012 03:12:27 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:49018) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TDryq-0003oR-7a for 8789@debbugs.gnu.org; Tue, 18 Sep 2012 03:12:25 -0400 Received: (qmail invoked by alias); 18 Sep 2012 07:11:04 -0000 Received: from 62-47-38-72.adsl.highway.telekom.at (EHLO [62.47.38.72]) [62.47.38.72] by mail.gmx.net (mp002) with SMTP; 18 Sep 2012 09:11:04 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18luCFAB54lFJWLGNwxBmJJwCxvk9w00yw5fc/xlg k8L8rk7wn4+/X3 Message-ID: <50581E7F.3040108@gmx.at> Date: Tue, 18 Sep 2012 09:10:55 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> In-Reply-To: <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 1. OK, I was not aware of that option; thanks. Please document it. (I do not > see it in either the Emacs manual or the Elisp manual.) It's not yet documented. > 2. I tried each of the values listed in the doc string. None of them had any > effect at all. Same broken behavior, always: the frame is deleted, then > re-created with the default size and position (i.e., ignoring its previous size > and position). That re-creation takes perhaps 0.5 sec or 1 sec, which means > that it is visually quite distracting, besides the fact that the size and > position prevent using the debugger efffectively (really, prevent using it at > all). > > I am using the regular Emacs debugger, not `edebug'. E.g., I am using > `debug-on-entry' etc. Dunno whether that is pertinent. The doc says nothing > about `edebug', in any case. I checked in a fix for this in revision 110085. Please try it. > 3. Wrt the new option's defcustom: If the documented four possible values are > the only possible values, then the defcustom should be rewritten so that the > user can choose (and can only choose) by using the Value Menu. S?he should not > have to or be allowed to enter a quoted symbol name in a text edit field. > > If the documented possible values are not the only possible values, then the doc > string should be updated to mention what other possible values there are and > what they do. > > This (#3) is a bug. Do you want me to file a separate bug report for it? I checked in a fix for this in the same revision. Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Sep 2012 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134797857131495 (code B ref 8789); Tue, 18 Sep 2012 14:30:02 +0000 Received: (at 8789) by debbugs.gnu.org; 18 Sep 2012 14:29:31 +0000 Received: from localhost ([127.0.0.1]:41913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDynq-0008Bw-Lm for submit@debbugs.gnu.org; Tue, 18 Sep 2012 10:29:30 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:26655) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDynp-0008Bl-Ak for 8789@debbugs.gnu.org; Tue, 18 Sep 2012 10:29:29 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8IES6KB001176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Sep 2012 14:28:07 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8IES5hb013550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 14:28:05 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8IES5oh010017; Tue, 18 Sep 2012 09:28:05 -0500 Received: from dradamslap1 (/10.159.221.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Sep 2012 07:28:04 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> Date: Tue, 18 Sep 2012 07:28:01 -0700 Message-ID: <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50581E7F.3040108@gmx.at> Thread-Index: Ac2VbMeESdIf3o0MQ/qn0Zr+JH0QygAPMhIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > It's not yet documented. OK. I guess it will be, before the code is in a release. Thx. > I checked in a fix for this in revision 110085. Please try it. > > > This (#3) is a bug. Do you want me to file a separate bug > > report for it? > > I checked in a fix for this in the same revision. Thanks for your fixes. I'll check the next Windows binary. - Drew From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134807327018107 (code B ref 8789); Wed, 19 Sep 2012 16:48:02 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 16:47:50 +0000 Received: from localhost ([127.0.0.1]:43889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TENRG-0004hz-4z for submit@debbugs.gnu.org; Wed, 19 Sep 2012 12:47:50 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:41814) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TENRD-0004hq-8i for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 12:47:48 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JGkJZl018184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 16:46:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8JGkIDQ024662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 16:46:19 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8JGkIft015138; Wed, 19 Sep 2012 11:46:18 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Sep 2012 09:46:18 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> Date: Wed, 19 Sep 2012 09:46:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> Thread-Index: Ac2VbMeESdIf3o0MQ/qn0Zr+JH0QygAPMhIgADbJmoA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) > Thanks for your fixes. I'll check the next Windows binary. - Drew I have not yet been able to do that (no Windows binary), but here is some more info. (I have not customized `debugger-bury-or-kill' - the value is still `bury'.) Sometimes I can grab the border of the *Backtrace* frame, as usual, and resize it (even though it goes back to the default size when I hit `d', as described earlier). But sometimes I cannot: as soon as I touch the mouse to the frame edge and try to drag it, the frame disappears! I can just touch it (e.g. click it) without it disappearing, but as soon as I try to drag the touched edge, the frame disappears. It does not matter which edge (e.g. bottom or right) I try to drag. No idea what is going on here - I have never seen anything like this. This happpens systematically when I enter the debugger in a certain context, and it never seems to happen otherwise. But that context is far too complex to try to communicate. Suffice it to say that this happens. When it happens I see nothing additional in *Messages*, and there is no crash. The *Backtrace* frame just disappears, and the mode line indicates that I am no longer in a recursive edit - IOW, the debugger is exited. And if I explicitly visit buffer *Backtrace*, I see that it is indeed empty. It is as if trying to drag the frame edge is (sometimes) the equivalent of hitting `q' in the debugger. Very weird. I'm sorry that I cannot offer more info about this. But clearly something is very wrong. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134807471920219 (code B ref 8789); Wed, 19 Sep 2012 17:12:02 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 17:11:59 +0000 Received: from localhost ([127.0.0.1]:43905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TENod-0005G4-Gu for submit@debbugs.gnu.org; Wed, 19 Sep 2012 13:11:59 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:40146) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TENob-0005Fx-Gt for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 13:11:59 -0400 Received: (qmail invoked by alias); 19 Sep 2012 17:10:29 -0000 Received: from 62-47-32-61.adsl.highway.telekom.at (EHLO [62.47.32.61]) [62.47.32.61] by mail.gmx.net (mp012) with SMTP; 19 Sep 2012 19:10:29 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18GWfNR6F0GWWYJ9FQHandHgSZn3eZLQ60M69Yq7U Nf+Bn6p9edaOGd Message-ID: <5059FC9C.8020702@gmx.at> Date: Wed, 19 Sep 2012 19:10:52 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Thanks for your fixes. I'll check the next Windows binary. - Drew > > I have not yet been able to do that (no Windows binary), It's trivial to get the change from say http://lists.gnu.org/archive/html/emacs-diffs/2012-09/msg00266.html and apply it. You don't have to rebuild Emacs for this change, just recompile debug.el. > but here is some more > info. (I have not customized `debugger-bury-or-kill' - the value is still > `bury'.) > > Sometimes I can grab the border of the *Backtrace* frame, as usual, and resize > it (even though it goes back to the default size when I hit `d', as described > earlier). This should have changed now. > But sometimes I cannot: as soon as I touch the mouse to the frame edge and try > to drag it, the frame disappears! I can just touch it (e.g. click it) without > it disappearing, but as soon as I try to drag the touched edge, the frame > disappears. It does not matter which edge (e.g. bottom or right) I try to drag. > > No idea what is going on here - I have never seen anything like this. > > This happpens systematically when I enter the debugger in a certain context, and > it never seems to happen otherwise. But that context is far too complex to try > to communicate. Suffice it to say that this happens. > > When it happens I see nothing additional in *Messages*, and there is no crash. > The *Backtrace* frame just disappears, and the mode line indicates that I am no > longer in a recursive edit - IOW, the debugger is exited. And if I explicitly > visit buffer *Backtrace*, I see that it is indeed empty. > > It is as if trying to drag the frame edge is (sometimes) the equivalent of > hitting `q' in the debugger. Looks like. Try with my change. Later we can try to put in some code immediately before the call to `quit-restore-window' to investigate the last command or input event that triggers this. martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 17:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134807516920921 (code B ref 8789); Wed, 19 Sep 2012 17:20:01 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 17:19:29 +0000 Received: from localhost ([127.0.0.1]:43927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TENvt-0005RO-Do for submit@debbugs.gnu.org; Wed, 19 Sep 2012 13:19:29 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:17019) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TENvr-0005RH-3R for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 13:19:28 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JHHvXV019729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 17:17:58 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8JHHuXt009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 17:17:57 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8JHHuQ1023059; Wed, 19 Sep 2012 12:17:56 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Sep 2012 10:17:56 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> Date: Wed, 19 Sep 2012 10:17:55 -0700 Message-ID: <2664C70F311C452F9DA8972AC97E32CA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2VbMeESdIf3o0MQ/qn0Zr+JH0QygAPMhIgADbJmoAAAQZMYA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) > It is as if trying to drag the frame edge is (sometimes) the > equivalent of hitting `q' in the debugger. > > Very weird. I'm sorry that I cannot offer more info about > this. But clearly something is very wrong. What's more, in that same context, if I do not try to drag the frame but I instead hit `d', I can step through the debugger once (a single `d'). The frame is removed and re-created, and *Backtrace* shows the effect of stepping (one step). But at that point hitting `d' again or `c' or `q' has no effect. Buffer *Backtrace* remains frozen with its same state. I need to select another frame and hit `C-]' (abort-recursive-edit) to exit the debugger (which removes frame *Backtrace*). After hitting `d' once, I tried clicking mouse-1 inside *Backtrace*, thinking that perhaps it did not have the focus. That either had no effect (clicking `d' etc. still did nothing) or it make the frame disappear and the debugger exit, i.e., just as it does when I try to resize it. If, instead of hitting `d' immediately, if I try to click mouse-1 inside *Backtrace*, either #1 or #2 happens: 1. (a) the click has no effect - I cannot, for example, select text there by dragging the mouse, and (b) the frame becomes insensitive to keyboard input: even the first `d' is unrecognized. 2. The frame disappears and the debugger exits. This is very weird behavior. As I said before, none of this happens with the Windows build of 2012-09-03. It happens with the build of 2012-09-17. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134807701423659 (code B ref 8789); Wed, 19 Sep 2012 17:51:02 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 17:50:14 +0000 Received: from localhost ([127.0.0.1]:43950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEOPd-00069Y-JA for submit@debbugs.gnu.org; Wed, 19 Sep 2012 13:50:13 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:43786) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEOPb-00069P-H0 for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 13:50:13 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JHmgKA020130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 17:48:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8JHmgqj016849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 17:48:42 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8JHmfxH028723; Wed, 19 Sep 2012 12:48:41 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Sep 2012 10:48:41 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> Date: Wed, 19 Sep 2012 10:48:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5059FC9C.8020702@gmx.at> Thread-Index: Ac2Wiaz0wWFoHcGOQ0K/Ps3KivYgbwAAanPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) > It's trivial to get the change from say > http://lists.gnu.org/archive/html/emacs-diffs/2012-09/msg00266.html > and apply it. You don't have to rebuild Emacs for this > change, just recompile debug.el. OK, I did that. I patched a copy of debug.el (MARTIN-debug.el) and loaded it. That changed nothing. I byte-compiled it and loaded that (MARTIN-debug.elc). That changed nothing. Everything I have described today still behaved the same, unfortunately. > > Sometimes I can grab the border of the *Backtrace* frame, > > as usual, and resize it (even though it goes back to the > > default size when I hit `d', as described earlier). > > This should have changed now. No, it did not appear to have changed - see above. OK, so I quit that Emacs session and started a new one. Loaded the patched debug code first (MARTIN-debug.el). Now I no longer see the bizarre debugger effects I described today. Perhaps something was weird about that session; dunno. And I can now resize and reposition the *Backtrace* frame as I could in the past. So it seems that this bug is fixed. Thank you. However, some things still seem weird. Dunno whether they happen because I loaded the MARTIN-debug.elc file (patched debug.el) after the original debug.elc had already been loaded. Sometimes during stepping it does blow away my frame and re-create the frame at the original position and with the original size. Not sure whether everything is fixed, but feel free to close the bug if you are done fixing. I can always reopen the bug if I find something else. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 20:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13480872516469 (code B ref 8789); Wed, 19 Sep 2012 20:41:01 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 20:40:51 +0000 Received: from localhost ([127.0.0.1]:44041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TER4l-0001gI-7W for submit@debbugs.gnu.org; Wed, 19 Sep 2012 16:40:51 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:38892) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TER4h-0001g5-9D for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 16:40:48 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JKdImG007257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 20:39:19 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8JKdICI004796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 20:39:18 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8JKdH4d022321; Wed, 19 Sep 2012 15:39:17 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Sep 2012 13:39:17 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at> Date: Wed, 19 Sep 2012 13:39:16 -0700 Message-ID: <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2Wiaz0wWFoHcGOQ0K/Ps3KivYgbwAAanPwAAaKqvA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) There seem still to be problems. emacs -Q M-x load-file MARTIN-debug.elc ;; That's debug.el, with your patch. ;; If I load the .el instead of the .elc, then the debugger is ;; called even for implement-debugger etc. - a mess. M-x load-library files.el M-x debug-on-entry file-remote-p That puts me immediately into the debugger, with a call to `file-remote-p'. Why does debugging file-remote-p cause the debugger to enter even for that M-x invocation? There is not even any reading of a file name. Thereafter, I cannot exit the debugger, no matter what I do. `c' and `q' seem to do nothing. `d' just steps into `file-remote-p'. Even `C-]' does not exit the debugger. I can use C-x k to kill the *Backtrace* buffer, but that leaves Emacs in a recursive edit, and `C-]' then brings Emacs back into the debugger. After the `C-x k', *Messages* shows this multiple times, always ending by entering: Entering debugger... Quit Entering debugger... Quit Entering debugger... Quit Entering debugger... Quit Entering debugger... This really seems to be a mess. For me, the debugger is not usable now, even with emacs -Q. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 20:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13480882547928 (code B ref 8789); Wed, 19 Sep 2012 20:58:01 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Sep 2012 20:57:34 +0000 Received: from localhost ([127.0.0.1]:44052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TERKv-00023p-Ms for submit@debbugs.gnu.org; Wed, 19 Sep 2012 16:57:34 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:42865) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TERKs-00023f-Lb for 8789@debbugs.gnu.org; Wed, 19 Sep 2012 16:57:32 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JKu0fu032642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Sep 2012 20:56:01 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8JKu04a000081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Sep 2012 20:56:00 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8JKu080014767; Wed, 19 Sep 2012 15:56:00 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Sep 2012 13:56:00 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> Date: Wed, 19 Sep 2012 13:55:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> Thread-Index: Ac2Wiaz0wWFoHcGOQ0K/Ps3KivYgbwAAanPwAAaKqvAAAMGhAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.5 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.5 (-------) Here's another problem. I would have reported it as a separate bug, but since I ran into it after loading your patched debug.el I thought perhaps it is best to report it here. emacs -Q M-x load-file MARTIN-debug.elc M-x load-library files.el M-x debug-on-entry file-name-nondirectory C-x 4 f ; or something else, to enter the debugger In the debugger: hit `e' and enter `last-command', to evaluate that variable. I get this error: call-interactively: Wrong type argument: stringp, nil You should be able to evaluate a variable using `e' in the debugger. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 13:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13481491056149 (code B ref 8789); Thu, 20 Sep 2012 13:52:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 13:51:45 +0000 Received: from localhost ([127.0.0.1]:44871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEhAO-0001b7-GV for submit@debbugs.gnu.org; Thu, 20 Sep 2012 09:51:44 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:32862) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TEhAL-0001ay-L2 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 09:51:42 -0400 Received: (qmail invoked by alias); 20 Sep 2012 13:50:09 -0000 Received: from 62-47-47-193.adsl.highway.telekom.at (EHLO [62.47.47.193]) [62.47.47.193] by mail.gmx.net (mp004) with SMTP; 20 Sep 2012 15:50:09 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+OuZIm5JqODcAVXzsL4OA+s1XimL25NLKukaOS8v MPO5xKx6HLE5Fe Message-ID: <505B1F26.20209@gmx.at> Date: Thu, 20 Sep 2012 15:50:30 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> In-Reply-To: <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > emacs -Q > > M-x load-file MARTIN-debug.elc > > ;; That's debug.el, with your patch. > ;; If I load the .el instead of the .elc, then the debugger is > ;; called even for implement-debugger etc. - a mess. > > M-x load-library files.el > > M-x debug-on-entry file-remote-p > > That puts me immediately into the debugger, with a call to `file-remote-p'. Why > does debugging file-remote-p cause the debugger to enter even for that M-x > invocation? There is not even any reading of a file name. > > Thereafter, I cannot exit the debugger, no matter what I do. `c' and `q' seem > to do nothing. `d' just steps into `file-remote-p'. Even `C-]' does not exit > the debugger. I can use C-x k to kill the *Backtrace* buffer, but that leaves > Emacs in a recursive edit, and `C-]' then brings Emacs back into the debugger. > After the `C-x k', *Messages* shows this multiple times, always ending by > entering: > > Entering debugger... > Quit > Entering debugger... > Quit > Entering debugger... > Quit > Entering debugger... > Quit > Entering debugger... > > This really seems to be a mess. For me, the debugger is not usable now, even > with emacs -Q. Suppose I do (progn (load-library "files.el") (debug-on-entry 'file-remote-p)) then I can observe the same behavior as you, more or less. Emacs 23 reacts in precisely the same manner here. Emacs 22 doesn't. So this is something that must have changed in between these two versions. I don't have the slightest idea what may have caused this and whether this qualifies as an error. martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 13:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.13481491146173 (code B ref 8789); Thu, 20 Sep 2012 13:52:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 13:51:54 +0000 Received: from localhost ([127.0.0.1]:44875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEhAY-0001bW-24 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 09:51:54 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:33685) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TEhAW-0001bP-KW for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 09:51:53 -0400 Received: (qmail invoked by alias); 20 Sep 2012 13:50:16 -0000 Received: from 62-47-47-193.adsl.highway.telekom.at (EHLO [62.47.47.193]) [62.47.47.193] by mail.gmx.net (mp030) with SMTP; 20 Sep 2012 15:50:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/+gFxt18P+kAjTfMbrbCYEwLh8GqS/v/aYhQxGS1 PfD6ufpa4g2wqk Message-ID: <505B1F2D.8050609@gmx.at> Date: Thu, 20 Sep 2012 15:50:37 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > emacs -Q > > M-x load-file MARTIN-debug.elc > > M-x load-library files.el > > M-x debug-on-entry file-name-nondirectory > > C-x 4 f ; or something else, to enter the debugger > > In the debugger: hit `e' and enter `last-command', to evaluate that variable. > > I get this error: > > call-interactively: Wrong type argument: stringp, nil > > You should be able to evaluate a variable using `e' in the debugger. My bad. I inadvertently removed an assignment in `debug'. Should work now as before. You can pick the change here: http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/110113 Thanks, martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134816097123923 (code B ref -1); Thu, 20 Sep 2012 17:10:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Sep 2012 17:09:31 +0000 Received: from localhost ([127.0.0.1]:45476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEkFn-0006Do-50 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 13:09:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39160) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEkFj-0006De-HS for submit@debbugs.gnu.org; Thu, 20 Sep 2012 13:09:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEkE7-0004TX-5s for submit@debbugs.gnu.org; Thu, 20 Sep 2012 13:07:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,RCVD_IN_XBL autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:52723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkE7-0004TT-2n for submit@debbugs.gnu.org; Thu, 20 Sep 2012 13:07:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkE3-0006CR-5a for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 13:07:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEkE2-0004Sx-64 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 13:07:43 -0400 Received: from mout.web.de ([212.227.17.11]:62823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEkE1-0004Sj-TA for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 13:07:42 -0400 Received: from snow.dragon ([89.204.138.21]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MbhNZ-1Sxtd81WWD-00IoXD; Thu, 20 Sep 2012 19:07:40 +0200 From: Michael Heerdegen References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> Date: Thu, 20 Sep 2012 19:10:08 +0200 In-Reply-To: <505B1F26.20209@gmx.at> (martin rudalics's message of "Thu, 20 Sep 2012 15:50:30 +0200") Message-ID: <87ehlwzklr.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:Qja2tc/FaNEDhAhiyd/yeq3rJr2myMCoF2mdaPD1k22 YqurNMNlIIGvZDOr8WROh1itJsK0wB8iFMILgd+e38adcoV3aM Kyb946m+dmdUMhZpLhCwE+6Pdgt+lXhd3U0zCzv0fNZBYTQxUQ G70nRSB8JTQ8JC7FbRdvnep/6iMwwh7j9wkt7JL+xwfWP7f3uQ txys70eB6q/IEozaeCPdrnBOtq3M/YWD/yBMI3diQw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) martin rudalics writes: > Suppose I do > > (progn > (load-library "files.el") > (debug-on-entry 'file-remote-p)) > > then I can observe the same behavior as you, more or less. > > Emacs 23 reacts in precisely the same manner here. Emacs 22 doesn't. > So this is something that must have changed in between these two > versions. I don't have the slightest idea what may have caused this and > whether this qualifies as an error. It's caused by the calculation of the mode-line. Try this: (setq-default mode-line-remote nil) and the problem is gone. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 17:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134816203425471 (code B ref 8789); Thu, 20 Sep 2012 17:28:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 17:27:14 +0000 Received: from localhost ([127.0.0.1]:45515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEkWv-0006cl-WB for submit@debbugs.gnu.org; Thu, 20 Sep 2012 13:27:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:50882) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TEkWu-0006cd-HG for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 13:27:13 -0400 Received: (qmail invoked by alias); 20 Sep 2012 17:25:38 -0000 Received: from 62-47-58-200.adsl.highway.telekom.at (EHLO [62.47.58.200]) [62.47.58.200] by mail.gmx.net (mp071) with SMTP; 20 Sep 2012 19:25:38 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/GG4sqGQzGW7vWuecNOlAuKKqqPaAdjIFWN/KEtu QfVjZic4XMqSfV Message-ID: <505B51AD.2080908@gmx.at> Date: Thu, 20 Sep 2012 19:26:05 +0200 From: martin rudalics MIME-Version: 1.0 References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> In-Reply-To: <87ehlwzklr.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Emacs 23 reacts in precisely the same manner here. Emacs 22 doesn't. >> So this is something that must have changed in between these two >> versions. I don't have the slightest idea what may have caused this and >> whether this qualifies as an error. > > It's caused by the calculation of the mode-line. Try this: > > (setq-default mode-line-remote nil) > > and the problem is gone. Good catch ;-) So the solution is probably to never enable `debug-on-entry' for functions that run through the mode-line mechanism. martin From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 18:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" , "'Michael Heerdegen'" Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134816460729190 (code B ref 8789); Thu, 20 Sep 2012 18:11:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 18:10:07 +0000 Received: from localhost ([127.0.0.1]:45544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElCQ-0007al-R8 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 14:10:07 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:18328) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElCP-0007ae-9T for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 14:10:06 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KI8T0b026045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 18:08:30 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KI8S25026324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 18:08:28 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KI8ReT024759; Thu, 20 Sep 2012 13:08:27 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 11:08:27 -0700 From: "Drew Adams" References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at><87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> Date: Thu, 20 Sep 2012 11:08:26 -0700 Message-ID: <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <505B51AD.2080908@gmx.at> Thread-Index: Ac2XVRVcv+DoQ+x+T1mwbWW5HvNw+AABN8SA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > > It's caused by the calculation of the mode-line. Try this: > > (setq-default mode-line-remote nil) > > and the problem is gone. > > So the solution is probably to never enable `debug-on-entry' for > functions that run through the mode-line mechanism. That does not sound like the solution to me. That sounds like giving up on using the debugger. What does "run through the mode-line mechanism" even mean, and how does a user tell whether a given function might "run through..."? And for such functions (whatever that might mean), what workaround do you propose, to get the effect of `debug-on-entry'. This is a regression, and should just be fixed. Users should not have to work around it or jump over it - that is not "the solution". `mode-line-remote' was introduced in Emacs 23. If it is that introduction that introduced this regression then that change needs to be fixed somehow, or reverted. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 18:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" Cc: 'Michael Heerdegen' , 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134816544930391 (code B ref 8789); Thu, 20 Sep 2012 18:25:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 18:24:09 +0000 Received: from localhost ([127.0.0.1]:45571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElQ0-0007u8-V7 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 14:24:09 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:31002) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElPy-0007u1-T1 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 14:24:07 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KIMUl6007828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 18:22:30 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KIMTE4003455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 18:22:30 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KIMTCw002242; Thu, 20 Sep 2012 13:22:29 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 11:22:29 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at><87haz0po82.fsf@web.de><4F3BE4CB.3030909@gmx.at><4F3CB843.6030401@gmx.at><4F3D41DD.6080603@gmx.at><877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at><86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F2D.8050609@gmx.at> Date: Thu, 20 Sep 2012 11:22:28 -0700 Message-ID: <6E3A221E4BBC4C72A5AB4CB54046FDF8@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <505B1F2D.8050609@gmx.at> Thread-Index: Ac2XNuFyd+xxlrb7R2+qedIFlkAhDAAJeevw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > My bad. I inadvertently removed an assignment in `debug'. > Should work now as before. You can pick the change here: > > http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/110113 Thanks for the quick fix for that part. Confirmed OK. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: michael_heerdegen@web.de, rudalics@gmx.at, 8789@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134816593231106 (code B ref 8789); Thu, 20 Sep 2012 18:33:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 18:32:12 +0000 Received: from localhost ([127.0.0.1]:45576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElXn-00085f-Ou for submit@debbugs.gnu.org; Thu, 20 Sep 2012 14:32:12 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:54748) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElXk-00085W-TI for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 14:32:09 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAN00L00VD5C600@a-mtaout20.012.net.il> for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 21:30:32 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAN00KFWVEWS6M0@a-mtaout20.012.net.il>; Thu, 20 Sep 2012 21:30:32 +0300 (IDT) Date: Thu, 20 Sep 2012 21:30:47 +0300 From: Eli Zaretskii In-reply-to: <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> X-012-Sender: halo1@inter.net.il Message-id: <83392czgvc.fsf@gnu.org> References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Thu, 20 Sep 2012 11:08:26 -0700 > Cc: 8789@debbugs.gnu.org > > > > It's caused by the calculation of the mode-line. Try this: > > > (setq-default mode-line-remote nil) > > > and the problem is gone. > > > > So the solution is probably to never enable `debug-on-entry' for > > functions that run through the mode-line mechanism. > > That does not sound like the solution to me. Please suggest another solution, then, for a function that is constantly called as part of redisplay (which is what happens here, see below). AFAIU, this is why you "cannot exit the debugger": anything that you do redisplays the mode line, and re-enters the debugger. > What does "run through the mode-line mechanism" even mean, It means functions that are called when some Lisp form is evaluated as part of displaying the mode line. > and how does a user tell whether a given function might "run through..."? By examining the C-level call stack, I presume. > And > for such functions (whatever that might mean), what workaround do you propose, > to get the effect of `debug-on-entry'. Why do you need a work-around? The feature works, it just has nasty side-effects due to the fact that the function is constantly called. > This is a regression, and should just be fixed. How do you "fix" situation where a function you want to debug is called at a very high frequency? The only way I know if is to stop calling it -- which is precisely what was suggested: set mode-line-remote to nil, which avoids the invocation of file-remote-p as part of mode-line redisplay. > > M-x debug-on-entry file-remote-p > > > > That puts me immediately into the debugger, with a call to `file-remote-p'. Why > > does debugging file-remote-p cause the debugger to enter even for that M-x > > invocation? Typing "M-x" causes redisplay of certain parts of the Emacs frame, including the mode line. And redisplaying the mode line calls file-remote-p because of mode-line-remote, which puts an indication of a file being remote on the mode line. > > There is not even any reading of a file name. The file name in question is buffer-file-name. > > Thereafter, I cannot exit the debugger, no matter what I do. `c' and `q' seem > > to do nothing. `d' just steps into `file-remote-p'. Even `C-]' does not exit > > the debugger. I can use C-x k to kill the *Backtrace* buffer, but that leaves > > Emacs in a recursive edit, and `C-]' then brings Emacs back into the You just re-enter the debugger again and again, and the indication is: > > After the `C-x k', *Messages* shows this multiple times, always ending by > > entering: > > > > Entering debugger... > > Quit > > Entering debugger... > > Quit > > Entering debugger... > > Quit > > Entering debugger... > > Quit > > Entering debugger... From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 18:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: michael_heerdegen@web.de, rudalics@gmx.at, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.1348167084477 (code B ref 8789); Thu, 20 Sep 2012 18:52:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 18:51:24 +0000 Received: from localhost ([127.0.0.1]:45610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElqN-00007e-P4 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 14:51:24 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:37500) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TElqK-00007W-PL for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 14:51:21 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KInjur003396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 18:49:46 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KInjJ1010924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 18:49:45 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KInjI9006683; Thu, 20 Sep 2012 13:49:45 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 11:49:45 -0700 From: "Drew Adams" References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> Date: Thu, 20 Sep 2012 11:49:43 -0700 Message-ID: <8123443E3625415F89A2118ECE393E72@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83392czgvc.fsf@gnu.org> Thread-Index: Ac2XXgf3nJn9qsniS3SjLoHE9ByvPAAAP/ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > > > So the solution is probably to never enable `debug-on-entry' for > > > functions that run through the mode-line mechanism. > > > > That does not sound like the solution to me. > > Please suggest another solution, then, for a function that is > constantly called as part of redisplay (which is what happens here, > see below). AFAIU, this is why you "cannot exit the debugger": > anything that you do redisplays the mode line, and re-enters the > debugger. Gee, Eli, I don't know what the solution is. Except maybe to revert the change that caused the regression. Or maybe the debugger should skip over such mode-line refreshing? I really don't know, sorry. I do know that there is all kinds of code, including user code, that calls `file-remote-p' - if nothing else, to avoid tramp digging in its heels and trying to access remote machines. If we cannot debug such code without first manually fiddling with the mode-line spec, then that's a sorry situation, IMHO. What users will even be aware that they will need to fiddle with such a workaround? A user stepping through code that happens to call `file-remote-p' at some point will be quite surprised, and will typically have no clue what to do at that point. > > What does "run through the mode-line mechanism" even mean, > > It means functions that are called when some Lisp form is evaluated as > part of displaying the mode line. I would say that it is indeed unfortunate if we are now calling `file-remote-p' as part of displaying the mode line. Sure, individual users can remove that. And sure, having an indication in the mode line of whether or not something is remote is nice. But if this is the price then I'd say we should find some other solution - i.e., some other way to add that feature. If nothing else, it might be enough to duplicate the code for `file-remote-p' as `mode-line-file-remote-p', and use only the latter for mode-line update. That should reduce interference with most Elisp code. I don't claim that is the best way to handle this. My point is that we should not have mode-line updating invoke `file-remote-p', if that means that breaking debugging, so that the debugger barfs and rebarfs whenever it invokes `file-remote-p'. > > and how does a user tell whether a given function might > "run through..."? > > By examining the C-level call stack, I presume. Wunderbar. Lisp debugger users now need to dig deeper into the bowels of Emacs. > > And for such functions (whatever that might mean), what > > workaround do you propose, to get the effect of `debug-on-entry'. > > Why do you need a work-around? The feature works, it just has nasty > side-effects due to the fact that the function is constantly called. IOW, it works but it just doesn't work, in practice. > > This is a regression, and should just be fixed. > > How do you "fix" situation where a function you want to debug is > called at a very high frequency? It should not be called for mode-line display. IMHO. That was a misguided enhancement. > The only way I know if is to stop > calling it -- which is precisely what was suggested: set > mode-line-remote to nil, which avoids the invocation of file-remote-p > as part of mode-line redisplay. Not as an individual user - that's just Emacs Dev punting. Perhaps the debugger could do that automatically. Whether it should or not, and whether that should be a user option, I also don't know. But we should not expect users to dig in and discover this stuff and work around it on an individual basis. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 20:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134817222010884 (code B ref -1); Thu, 20 Sep 2012 20:17:01 +0000 Received: (at submit) by debbugs.gnu.org; 20 Sep 2012 20:17:00 +0000 Received: from localhost ([127.0.0.1]:45655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnBD-0002pU-MX for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:16:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43570) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnAx-0002oy-Ot for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEn9Q-0005m0-Mk for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:15:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,RCVD_IN_XBL autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEn9Q-0005ls-Jf for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:15:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEn9P-0000Ba-EN for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:15:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEn9O-0005gh-E9 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:15:07 -0400 Received: from mout.web.de ([212.227.17.11]:63804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEn9O-0005e2-5a for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:15:06 -0400 Received: from snow.dragon ([89.204.130.212]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MYf78-1T0vNK2m38-00VpkB; Thu, 20 Sep 2012 22:15:05 +0200 From: Michael Heerdegen References: <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> Date: Thu, 20 Sep 2012 22:17:36 +0200 In-Reply-To: <83392czgvc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 20 Sep 2012 21:30:47 +0300") Message-ID: <87vcf8fnz3.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:sMEcXYecla/IYMvoLvjvzuZHw6hsupILH73GzsrXgGi 1QNkUmy/iQ0vcejOl5Lf45iw607oaSMuKJF4fbKEzRTAt3kxpL SAk3pAgsjleJ/l3j86JU8GCbFquvxo2MOeyXyiGT148YwRHruH pfIm12z0/9RKXy1kH4Ghqj40Jf4oljBuf6CDb8UuPWa8pAioM3 sm7fQM1b2nnKTRHm8+7Ab5MH4FmW2Mo5RJ9PDkZbuU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) Eli Zaretskii writes: > > > So the solution is probably to never enable `debug-on-entry' for > > > functions that run through the mode-line mechanism. > > > > That does not sound like the solution to me. I don't see this as critical as Drew, IMHO this is not really a bug. It is consistent behavior, and sometimes it can useful to be able to enter the debugger from code run by redisplaying. But OTOH, invoking the debugger in such situations can (a) be surprising, and even a experienced user may take some time to see what's happening. And, b), it is not what you want most of the time. So, what would be cool is a user-option for that behavior. The default could be to not invoke the debugger from redisplay code. A question would be how to handle similar stuff, like menu calculation, things in pre|post-command-hook, code run by timers, etc. I mean all the stuff that is not run directly while processing a user command. If such an option could easily be implemented, that would be fine. But if it would be too much work, I also could live without it. I can use `debug' to invoke the debugger directly, which prevents such surprises. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 20:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Michael Heerdegen'" , <8789@debbugs.gnu.org> Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817334812463 (code B ref 8789); Thu, 20 Sep 2012 20:36:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 20:35:48 +0000 Received: from localhost ([127.0.0.1]:45662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnTP-0003Ex-Aw for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:35:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:48497) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnTN-0003Eq-W8 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 16:35:46 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KKY9rQ009420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 20:34:10 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KKY85C013526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 20:34:09 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KKY8bS028915; Thu, 20 Sep 2012 15:34:08 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 13:34:08 -0700 From: "Drew Adams" References: <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at><2D8C133406A54B26AD253EC7EE52C666@us.oracle.com><505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de><505B51AD.2080908@gmx.at><91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com><83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> Date: Thu, 20 Sep 2012 13:34:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87vcf8fnz3.fsf@web.de> Thread-Index: Ac2XbLHe27Q3HR0RRdiembuVJ+BZ8QAAaKJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > I can use `debug' to invoke the debugger directly, which > prevents such surprises. 1. Not if you put `debug' in `file-remote-p'. Or in some function that then calls `file-remote-p. Or then calls some function that calls `file-remote-p'... This is not about `debug-on-entry', AFAICT. It is about the debugger debugging anything that might call `file-remote-p'. 2. You are right to have underlined the fact that there are other, similar areas that can be problematic for the debugger. A user option that lets you list such areas for the debugger to skip over could be useful. IOW, mode line and other redisplay would constitute one or more such optional list items. 3. But I also think that it should be enough, for this problematic mode line enhancement, to simply call a duplicate of `file-remote-p' and not `file-remote-p' itself, which is used by all kinds of code. If that duplicate (e.g., `mode-line-file-remote-p') is called only by the mode-line code then that should greatly reduce, if not eliminate, this problem for the debugger. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 20:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: michael_heerdegen@web.de, rudalics@gmx.at, 8789@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817375313130 (code B ref 8789); Thu, 20 Sep 2012 20:43:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 20:42:33 +0000 Received: from localhost ([127.0.0.1]:45667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnZw-0003Pj-Dt for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:42:32 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:41571) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnZs-0003PY-AR for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 16:42:30 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MAO008001CRF900@a-mtaout22.012.net.il> for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 23:40:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAO008HM1G4AA30@a-mtaout22.012.net.il>; Thu, 20 Sep 2012 23:40:53 +0300 (IDT) Date: Thu, 20 Sep 2012 23:41:07 +0300 From: Eli Zaretskii In-reply-to: <8123443E3625415F89A2118ECE393E72@us.oracle.com> X-012-Sender: halo1@inter.net.il Message-id: <83zk4kxw9o.fsf@gnu.org> References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <8123443E3625415F89A2118ECE393E72@us.oracle.com> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Cc: , , <8789@debbugs.gnu.org> > Date: Thu, 20 Sep 2012 11:49:43 -0700 > > > > > So the solution is probably to never enable `debug-on-entry' for > > > > functions that run through the mode-line mechanism. > > > > > > That does not sound like the solution to me. > > > > Please suggest another solution, then, for a function that is > > constantly called as part of redisplay (which is what happens here, > > see below). AFAIU, this is why you "cannot exit the debugger": > > anything that you do redisplays the mode line, and re-enters the > > debugger. > > Gee, Eli, I don't know what the solution is. Except maybe to revert the change > that caused the regression. > > Or maybe the debugger should skip over such mode-line refreshing? I really > don't know, sorry. Well, ideas are certainly welcome. It's a hard problem, given the potentially conflicting goals. I don't think removing the feature will be welcome. One such solution already exists: set inhibit-eval-during-redisplay to a non-nil value (it will inhibit _all_ calls to Lisp by all display features, though). I'm not sure how visible is that feature. Perhaps we need to advertise it more. > I do know that there is all kinds of code, including user code, that calls > `file-remote-p' - if nothing else, to avoid tramp digging in its heels and > trying to access remote machines. If we cannot debug such code without first > manually fiddling with the mode-line spec, then that's a sorry situation, IMHO. This is a potential problem with any code, C or Lisp, that runs during each redisplay cycle. On the C level, the only sane way of dealing with this is to use conditional breakpoints with cleverly designed conditions that cause the breakpoints break only when the function being debugged is called in the right context, bypassing the myriads of irrelevant calls. > I would say that it is indeed unfortunate if we are now calling `file-remote-p' > as part of displaying the mode line. Surely, there's nothing special in 'file-remote-p', except the fact that you needed to debug it in this case. Any code that is eval'ed as part of displaying the mode line, or redisplay in general, will be susceptible to similar problems. A solution specific to a single function won't do, would it? > > > This is a regression, and should just be fixed. > > > > How do you "fix" situation where a function you want to debug is > > called at a very high frequency? > > It should not be called for mode-line display. IMHO. That was a misguided > enhancement. I disagree. That indication is important when you work with remote files a lot. And again, this particular function is not the issue; the issue is more general. > > The only way I know if is to stop > > calling it -- which is precisely what was suggested: set > > mode-line-remote to nil, which avoids the invocation of file-remote-p > > as part of mode-line redisplay. > > Not as an individual user - that's just Emacs Dev punting. When you debug, you _are_ a developer. > Perhaps the debugger could do that automatically. Not unconditionally, because it is perfectly valid to debug code that runs off redisplay. > Whether it should or not, and whether that should be a user option, > I also don't know. But we should not expect users to dig in and > discover this stuff and work around it on an individual basis. Even if we have an option (please see if inhibit-eval-during-redisplay suits your needs), using it already requires to know or suspect that calls from redisplay are the reason for "strange" behavior during debugging. So I'm not sure I see how any such option will solve the problem of discoverability; again, ideas welcome. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 20:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817446714135 (code B ref 8789); Thu, 20 Sep 2012 20:55:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 20:54:27 +0000 Received: from localhost ([127.0.0.1]:45674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnlS-0003fv-Ot for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:54:26 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:56545) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnlQ-0003fn-V5 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 16:54:25 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAO00M001U1MX00@a-mtaout20.012.net.il> for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 23:51:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAO00MCQ1YBM820@a-mtaout20.012.net.il>; Thu, 20 Sep 2012 23:51:47 +0300 (IDT) Date: Thu, 20 Sep 2012 23:52:01 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83wqzoxvri.fsf@gnu.org> References: <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > Date: Thu, 20 Sep 2012 13:34:07 -0700 > > 3. But I also think that it should be enough, for this problematic mode line > enhancement, to simply call a duplicate of `file-remote-p' and not > `file-remote-p' itself, which is used by all kinds of code. > > If that duplicate (e.g., `mode-line-file-remote-p') is called only by the > mode-line code then that should greatly reduce, if not eliminate, this problem > for the debugger. This has 2 problems, at least: . what if I need to debug mode-line-file-remote-p? . what about calling Lisp from display features other than the mode line, such as tool-bar buttons and menu items? In general, I think this is a slippery slope: before long we will be duplicating many important functions, and we will have to enforce some kind of coding standards whereby redisplay features cannot call "ordinary" functions. I think this is absurd. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 21:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: michael_heerdegen@web.de, rudalics@gmx.at, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817484714706 (code B ref 8789); Thu, 20 Sep 2012 21:01:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 21:00:47 +0000 Received: from localhost ([127.0.0.1]:45681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnra-0003p8-Hl for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:00:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:43013) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnrY-0003p1-1M for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 17:00:45 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KKx8Li001669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 20:59:09 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KKx7n2021658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 20:59:08 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KKx7Ct032461; Thu, 20 Sep 2012 15:59:07 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 13:59:07 -0700 From: "Drew Adams" References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <8123443E3625415F89A2118ECE393E72@us.oracle.com> <83zk4kxw9o.fsf@gnu.org> Date: Thu, 20 Sep 2012 13:59:06 -0700 Message-ID: <9858A6718B624C2798943F59CEDFB74E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83zk4kxw9o.fsf@gnu.org> Thread-Index: Ac2XcD4+2KkQ4gnvTSazDMS7vYFPaAAAICWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > One such solution already exists: set inhibit-eval-during-redisplay to > a non-nil value (it will inhibit _all_ calls to Lisp by all display > features, though). I'm not sure how visible is that feature. Perhaps > we need to advertise it more. More than what? ;-) I never heard of it. And it does not appear to be documented in the Elisp manual. But how about an option that does that only for eval when the debugger is active? IOW, that sounds like something that is a broader brush than what is needed here. > This is a potential problem with any code, C or Lisp, that runs during > each redisplay cycle. On the C level, the only sane way of dealing > with this is to use conditional breakpoints with cleverly designed > conditions that cause the breakpoints break only when the function > being debugged is called in the right context, bypassing the myriads > of irrelevant calls. > > > I would say that it is indeed unfortunate if we are now > > calling `file-remote-p' as part of displaying the mode line. > > Surely, there's nothing special in 'file-remote-p', except the fact > that you needed to debug it in this case. No, of course there is nothing special about it. The point is that it is a commonly called function, and now it is also called to display the mode line. That is a powder-keg combination. That is the problem. It is asking for trouble to call such a function as part of the mode-line display. > Any code that is eval'ed as > part of displaying the mode line, or redisplay in general, will be > susceptible to similar problems. Precisely. > A solution specific to a single function won't do, would it? It would do for this particular bug. ;-) But yes, the same principle and potential problem applies to all functions called during display of the mode line (or other redisplay stuff). > > > > This is a regression, and should just be fixed. > > > > > > How do you "fix" situation where a function you want to debug is > > > called at a very high frequency? > > > > It should not be called for mode-line display. IMHO. That > > was a misguided enhancement. > > I disagree. That indication is important when you work with remote > files a lot. No one said it was not useful. In fact, I explicitly said it was. > And again, this particular function is not the issue; > the issue is more general. Yes and no. Agreed that there is a general problem. But let's not let the perfect become the enemy of the good. This particular regression was introduced because `file-remote-p' is now called to update the mode line. Take care of that bug and you take care of that bug ;-), which is already a good thing. > > Perhaps the debugger could do that automatically. > > Not unconditionally, because it is perfectly valid to debug code that > runs off redisplay. Agreed. That's why I mentioned doing so optionally (and probably by default, to lessen surprise). > > Whether it should or not, and whether that should be a user option, > > I also don't know. But we should not expect users to dig in and > > discover this stuff and work around it on an individual basis. > > Even if we have an option (please see if inhibit-eval-during-redisplay > suits your needs), using it already requires to know or suspect that > calls from redisplay are the reason for "strange" behavior during > debugging. So I'm not sure I see how any such option will solve the > problem of discoverability; again, ideas welcome. Make it not only optional, but the default behavior for the debugger. No, I do not mean `inhibit-eval-during-redisplay', which paints with a broader brush. I mean an option to have the debugger skip over/through calls involving redisplay. But you ignored the simple solution I proposed: just make the mode-line code call a separate function from `file-remote-p'. That function can do the same thing, and it could even have exactly the same definition. But it would be called out as being something that is intended to be called only by the mode-line code. IOW, try to keep this separate and make that intention explicit. It seems to me that that would go a long way - maybe all the way - to preventing typical debugging from falling down the hole that this discussion is about. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 21:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Eli Zaretskii'" Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817559415725 (code B ref 8789); Thu, 20 Sep 2012 21:14:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 21:13:14 +0000 Received: from localhost ([127.0.0.1]:45689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEo3d-00045a-VS for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:13:14 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:32884) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEo3b-00045S-O4 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 17:13:12 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KLBa1u003203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 21:11:36 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KLBXYF017356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 21:11:34 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KLBXPh023008; Thu, 20 Sep 2012 16:11:33 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 14:11:33 -0700 From: "Drew Adams" References: <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> <83wqzoxvri.fsf@gnu.org> Date: Thu, 20 Sep 2012 14:11:30 -0700 Message-ID: <705175AEA01C48549771E311A473EE28@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83wqzoxvri.fsf@gnu.org> Thread-Index: Ac2XcefRFciJRWSeT72WFFNpUdUbSAAAN8/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > > 3. But I also think that it should be enough, for this > > problematic mode line enhancement, to simply call a > > duplicate of `file-remote-p' and not `file-remote-p' > > itself, which is used by all kinds of code. > > > > If that duplicate (e.g., `mode-line-file-remote-p') is > > called only by the mode-line code then that should > > greatly reduce, if not eliminate, this problem > > for the debugger. > > This has 2 problems, at least: > > . what if I need to debug mode-line-file-remote-p? Just do it. With the same problems you encounter today - no more and no less. The point is that the number of people who would, today, fall upon this `file-remote-p' sword accidentally _far_ outnumbers the people who will need to debug `mode-line-remote-p'. And those in the latter group will be likely to do so with cognizance of cause. Not so those in the first group. That's the (should-be-obvious) point: `file-remote-p' is called all over the place, by code that has nothing at all to do with the mode line or redisplay. `mode-line-file-remote-p' would have as its raison d'etre to be called only by mode-line code. > . what about calling Lisp from display features other than the mode > line, such as tool-bar buttons and menu items? Hey, I have nothing against your coming up with an elegant, general solution. But while waiting, why not solve the problem at hand? If you later manage to square the circle, then you can rename `mode-line-file-remote-p' back to `file-remote-p'. Easy. > In general, I think this is a slippery slope: before long we will be > duplicating many important functions, and we will have to enforce some > kind of coding standards whereby redisplay features cannot call > "ordinary" functions. I think this is absurd. You are exaggerating. If you have a better, immediate solution, please go for it. Or if you want to revert the change that caused the regression, go for it. But if you just want to wave your hands wildly about this not being the only problem, then I say, again, let's not let the perfect become the enemy of the good. In sum, I do not claim that my suggestion is the only or the best possible solution. Better ideas are welcome. But let's not avoid solving the problem just because there are potentially other, similar problems. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 21:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134817629916706 (code B ref -1); Thu, 20 Sep 2012 21:25:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Sep 2012 21:24:59 +0000 Received: from localhost ([127.0.0.1]:45694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEoF0-0004LO-5T for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:24:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45254) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEoEy-0004LH-Bj for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:24:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEoDR-0004ug-R4 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:23:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,RCVD_IN_XBL autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:53251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEoDR-0004uX-O1 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:23:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEoDQ-0000TT-LV for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:23:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEoDP-0004uA-Iw for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:23:20 -0400 Received: from mout.web.de ([212.227.17.11]:64968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEoDP-0004u6-9r for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:23:19 -0400 Received: from snow.dragon ([89.204.130.212]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LrbLR-1TdnE81DNl-013LuB; Thu, 20 Sep 2012 23:23:18 +0200 From: Michael Heerdegen References: <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> Date: Thu, 20 Sep 2012 23:25:39 +0200 In-Reply-To: (Drew Adams's message of "Thu, 20 Sep 2012 13:34:07 -0700") Message-ID: <87obl0fkto.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:0f6geOeHNwnRdah96mC86JB+JpvbDFr8gVQSSmTylxq Ilb8wQdzp+W1ptgNrwyGWtgP2m88eMbq1csTaEDby6TI8siWbl xyGMS7iigWXzVVfphuE1d7JrKekAYr2k3btZY3B9IF7oHS/x2u 7Ol1CbHb+QOcriLl8puo9hgmd526CRQ91vXygxrglR0qvTmaVx QY85rVm+p/JZpy7ZbHgRXcIBqsWxMa8HnyOTzZzWak= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) "Drew Adams" writes: > > I can use `debug' to invoke the debugger directly, which > > prevents such surprises. > > 1. Not if you put `debug' in `file-remote-p'. Or in some function > that then calls `file-remote-p. Or then calls some function that > calls file-remote-p'... I agree that this is problematic. > 3. But I also think that it should be enough, for this problematic > mode line enhancement, to simply call a duplicate of `file-remote-p' > and not `file-remote-p' itself, which is used by all kinds of code. > > If that duplicate (e.g., `mode-line-file-remote-p') is called only by > the mode-line code then that should greatly reduce, if not eliminate, > this problem for the debugger. But do you really think that this is the right approach? E.g. in dired+, we use (:eval ...) in the dired mode-string. It's not very useful to create a duplicate of all lisp functions we call in this form only because of the fact that they are used for the mode-line. And, in the case of `file-remote-p', it wouldn't even be enough to duplicate just this function. We would have to duplicate any function that could be called by `file-remote-p' as well. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 21:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Michael Heerdegen'" , <8789@debbugs.gnu.org> Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817687917545 (code B ref 8789); Thu, 20 Sep 2012 21:35:01 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 21:34:39 +0000 Received: from localhost ([127.0.0.1]:45698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEoOM-0004Yw-Sc for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:34:39 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:17797) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEoOK-0004Yp-Rd for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 17:34:37 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KLX2s5025609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 21:33:03 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KLX1wn016309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 21:33:02 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KLX1Om021923; Thu, 20 Sep 2012 16:33:01 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 14:33:01 -0700 From: "Drew Adams" References: <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at><2D8C133406A54B26AD253EC7EE52C666@us.oracle.com><505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de><505B51AD.2080908@gmx.at><91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com><83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> <87obl0fkto.fsf@web.de> Date: Thu, 20 Sep 2012 14:33:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87obl0fkto.fsf@web.de> Thread-Index: Ac2XdjaBz+sPrHUMRTGu3Kdw0+3PwgAAC6RA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > > 3. But I also think that it should be enough, for this problematic > > mode line enhancement, to simply call a duplicate of `file-remote-p' > > and not `file-remote-p' itself, which is used by all kinds of code. > > > > If that duplicate (e.g., `mode-line-file-remote-p') is > > called only by the mode-line code then that should greatly reduce, > > if not eliminate, this problem for the debugger. > > But do you really think that this is the right approach? E.g. in > dired+, we use (:eval ...) in the dired mode-string. It's not very > useful to create a duplicate of all lisp functions we call in > this form only because of the fact that they are used for the mode-line. Again, if you have an elegant, general solution, I'm all ears. We are confronted with a particular regression, caused by the new occurrence of calling `file-remote-p' when updating the mode line. Why not fix that? > And, in the case of `file-remote-p', it wouldn't even be enough to > duplicate just this function. We would have to duplicate any > function that could be called by `file-remote-p' as well. No, sorry, I don't see that. The problem is only calls to `file-remote-p', not also calls to `find-file-name-handler' (which is called by `file-remote-p') or calls to `if' or `funcall' (also called by `file-remote-p'). AFAICT, it does not matter that `mode-line-file-remote-p' would call `find-file-name-handler' or `if' or `funcall'. `M-x debug-on-entry file-remote-p', or adding `debug' to your (non mode-line) code that calls `file-remote-p', would not cause the debugger to open when `mode-line-file-remote-p' is called or when any of the functions it calls is called. But perhaps I'm missing something? From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 22:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8789@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134817846019731 (code B ref -1); Thu, 20 Sep 2012 22:01:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Sep 2012 22:01:00 +0000 Received: from localhost ([127.0.0.1]:45717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEonr-00058B-D5 for submit@debbugs.gnu.org; Thu, 20 Sep 2012 18:01:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48644) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEono-000584-LL for submit@debbugs.gnu.org; Thu, 20 Sep 2012 18:00:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEomI-0000GO-Ad for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:59:23 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,RCVD_IN_XBL autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:58593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEomI-0000GK-7U for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEomH-0005t1-Cy for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:59:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEomG-0000G8-KK for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:59:21 -0400 Received: from mout.web.de ([212.227.15.4]:63143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEomG-0000G4-Ax for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:59:20 -0400 Received: from snow.dragon ([89.204.130.212]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0MarZy-1SuY6W1QOQ-00Kg8L; Thu, 20 Sep 2012 23:59:18 +0200 From: Michael Heerdegen References: <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de> <87obl0fkto.fsf@web.de> Date: Fri, 21 Sep 2012 00:01:51 +0200 In-Reply-To: (Drew Adams's message of "Thu, 20 Sep 2012 14:33:00 -0700") Message-ID: <87d31gfj5c.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:qkg2PkzU07PPfSr4Vzo1dP2XnGsYMdsXpEnworvmsJO 0NtApE2YfPvTRhzFXg5ueY0SavZ1uVGgpDUHWMnNHD72cutT4U BGPZmCuQhmnP1pvHjUtE1aSbhLfRWZq+Rlc1k7wFOivaI4DKt2 TP1EhJUg4FZCqTEynuJhPzsldqKAdM4Z0gB+mQwweWJmaAlS4H QLr6GgLYm/ytsg2dOE8+mwHfueB+XOcI79/Nb/dI8g= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -5.6 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) "Drew Adams" writes: > > And, in the case of `file-remote-p', it wouldn't even be enough to > > duplicate just this function. We would have to duplicate any > > function that could be called by `file-remote-p' as well. > > No, sorry, I don't see that. The problem is only calls to > file-remote-p', not > also calls to `find-file-name-handler' (which is called by > file-remote-p') or > calls to `if' or `funcall' (also called by `file-remote-p'). > > AFAICT, it does not matter that `mode-line-file-remote-p' would call > `find-file-name-handler' or `if' or `funcall'. `M-x debug-on-entry > file-remote-p', or adding `debug' to your (non mode-line) code that > calls `file-remote-p', would not cause the debugger to open when > `mode-line-file-remote-p' is called or when any of the functions it > calls is called. But what if you want to M-x debug-on-entry find-file-name-handler or any other function called by `file-remote-p' (or your mode-line version)? Going to bed now - good night. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 22:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Drew Adams" Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org, 'Eli Zaretskii' Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817943121236 (code B ref 8789); Thu, 20 Sep 2012 22:18:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 22:17:11 +0000 Received: from localhost ([127.0.0.1]:45772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEp3W-0005WS-Iw for submit@debbugs.gnu.org; Thu, 20 Sep 2012 18:17:11 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39676) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEp3U-0005WG-Cn for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 18:17:09 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q8KMFVmd016527; Thu, 20 Sep 2012 18:15:31 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id D6238B4071; Thu, 20 Sep 2012 18:15:30 -0400 (EDT) From: Stefan Monnier Message-ID: References: <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <8123443E3625415F89A2118ECE393E72@us.oracle.com> <83zk4kxw9o.fsf@gnu.org> <9858A6718B624C2798943F59CEDFB74E@us.oracle.com> Date: Thu, 20 Sep 2012 18:15:30 -0400 In-Reply-To: <9858A6718B624C2798943F59CEDFB74E@us.oracle.com> (Drew Adams's message of "Thu, 20 Sep 2012 13:59:06 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -4.1 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.1 (----) > But how about an option that does that only for eval when the debugger is > active? IOW, that sounds like something that is a broader brush than what is > needed here. There are 2 different situations: 1- calling the debugger while it's already active. This can easily be avoided by checking inhibit-debugger. `debug-on-error' already does that, and it would probably make sense to make debug-on-entry do it as well. 2- calling the debugger from a function that's called all the time. I think in the file-remote-p case, we'll hit this one, which means that every time you exit the debugger you'll get right back into it. Emacs is not rendered unusable, but if you're trying to debug an unrelated call to that function, you're out of luck. Number 2 can be solved by making the breakpoint conditional on some predicate which might check the backtrace to determine the context of the call. Stefan From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 23:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'Michael Heerdegen'" , <8789@debbugs.gnu.org> Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134818310726426 (code B ref 8789); Thu, 20 Sep 2012 23:19:02 +0000 Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 23:18:27 +0000 Received: from localhost ([127.0.0.1]:45815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEq0o-0006sB-Ue for submit@debbugs.gnu.org; Thu, 20 Sep 2012 19:18:27 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:37891) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEq0m-0006s3-69 for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 19:18:25 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KNGlej014254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 23:16:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KNGk5d025241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 23:16:47 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KNGkvx017456; Thu, 20 Sep 2012 18:16:46 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 16:16:46 -0700 From: "Drew Adams" References: <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de><9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com><5057A4A3.4010100@gmx.at><4617F483F2CC446D980DF7194E06BB3A@us.oracle.com><50581E7F.3040108@gmx.at><1C1E224E1D674670BEE043B4A35A271F@us.oracle.com><5059FC9C.8020702@gmx.at><2D8C133406A54B26AD253EC7EE52C666@us.oracle.com><505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de><505B51AD.2080908@gmx.at><91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com><83392czgvc.fsf@gnu.org> <87vcf8fnz3.fsf@web.de><87obl0fkto.fsf@web.de> <87d31gfj5c.fsf@web.de> Date: Thu, 20 Sep 2012 16:16:44 -0700 Message-ID: <32E7DBF673DB42008F29E60802EF352E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87d31gfj5c.fsf@web.de> Thread-Index: Ac2XeznLw4jkdmkLQ0qSLFkGs59EfwACTipg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -7.4 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) > But what if you want to M-x debug-on-entry > find-file-name-handler or any other function called by > `file-remote-p' (or your mode-line version)? Yes of course, agreed. If you explicitly access the debugger intentionally for `find-file-name-handler', `if', or `funcall' (the 3 fns called by `file-remote-p'), then you will run into the same problem. The proposed fix would nevertheless be a big improvement. And you will not run into such a problem if you debug other code that calls any of those three fns or `file-remote-p'. That was my point. I think you are perhaps exaggerating the problems, _in practice_, that such a simple fix might not handle, and you are perhaps downplaying the real problem already caused by the regression. IOW, while Someone (TM) works on an elegant, general fix, implementing a simple fix that does a pretty good job now is better than doing nothing now and until that general fix is available. From unknown Tue Jun 24 22:39:01 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Pete Beardmore Subject: bug#8789: closed (Re: bug#8789: 23.3; debug backtrace buffer changes window on step-through) Message-ID: References: <506C01A9.1080406@gmx.at> X-Gnu-PR-Message: they-closed 8789 X-Gnu-PR-Package: emacs Reply-To: 8789@debbugs.gnu.org Date: Wed, 03 Oct 2012 09:14:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1349255642-7054-1" This is a multi-part message in MIME format... ------------=_1349255642-7054-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #8789: 23.3; debug backtrace buffer changes window on step-through which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 8789@debbugs.gnu.org. --=20 8789: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8789 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1349255642-7054-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 8789-done) by debbugs.gnu.org; 3 Oct 2012 09:13:41 +0000 Received: from localhost ([127.0.0.1]:38612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJL1R-0001p7-2S for submit@debbugs.gnu.org; Wed, 03 Oct 2012 05:13:41 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:41905) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TJL1O-0001p0-Nn for 8789-done@debbugs.gnu.org; Wed, 03 Oct 2012 05:13:39 -0400 Received: (qmail invoked by alias); 03 Oct 2012 09:13:00 -0000 Received: from 62-47-56-28.adsl.highway.telekom.at (EHLO [62.47.56.28]) [62.47.56.28] by mail.gmx.net (mp031) with SMTP; 03 Oct 2012 11:13:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+7YScSK9u7nfzFTDSgCP3ShLUU+DlCG6JiCM5ZWY TVm0iNvL/0S10n Message-ID: <506C01A9.1080406@gmx.at> Date: Wed, 03 Oct 2012 11:13:13 +0200 From: martin rudalics MIME-Version: 1.0 To: 8789-done@debbugs.gnu.org Subject: Re: bug#8789: 23.3; debug backtrace buffer changes window on step-through References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> In-Reply-To: <504B4940.9000809@gmx.at> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 8789-done Cc: michael_heerdegen@web.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > I now checked in a fix for this in revision 109937 on trunk. Bug closed. For related problems that emerged in the discussion please submit a new bug report. martin ------------=_1349255642-7054-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Jun 2011 17:27:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSBgK-0003lQ-9v for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:40 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QSBgE-0003lA-Ow for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSBg8-0003GZ-6c for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:29 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_NONE,RECEIVED_FROM_WINDOWS_HOST, RFC_ABUSE_POST,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:38590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg7-0003GV-T6 for submit@debbugs.gnu.org; Thu, 02 Jun 2011 13:27:27 -0400 Received: from eggs.gnu.org ([140.186.70.92]:50997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg6-0006PT-47 for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSBg2-0003Fs-T5 for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:25 -0400 Received: from blu0-omc1-s14.blu0.hotmail.com ([65.55.116.25]:19889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBg2-0003FW-Jy for bug-gnu-emacs@gnu.org; Thu, 02 Jun 2011 13:27:22 -0400 Received: from BLU0-SMTP178 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Jun 2011 10:07:19 -0700 X-Originating-IP: [78.86.149.244] X-Originating-Email: [pete.beardmore@msn.com] Message-ID: Received: from elservo.localdomain ([78.86.149.244]) by BLU0-SMTP178.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Jun 2011 10:07:18 -0700 Received: by elservo.localdomain (Postfix, from userid 80) id BB06FADAB0; Thu, 2 Jun 2011 18:07:16 +0100 (BST) Received: from elbeardo.lemondedelabarbe (elbeardo.lemondedelabarbe [10.0.0.5]) by elservo.lemondedelabarbe (Horde Framework) with HTTP; Thu, 02 Jun 2011 18:07:16 +0100 Date: Thu, 2 Jun 2011 18:07:16 +0100 From: Pete Beardmore To: bug-gnu-emacs@gnu.org Subject: 23.3; debug backtrace buffer changes window on step-through MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; delsp=Yes; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-OriginalArrivalTime: 02 Jun 2011 17:07:19.0097 (UTC) FILETIME=[87C28A90:01CC2147] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP4, XP SP1+ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Hi, A couple of my frame window layouts cause the emacs debugger's backtrace buffer to cycle between several windows when stepping through code, making it very difficult to focus. Please follow the minimal steps below to re-produce this undesirable behaviour, also confirmed as present by another user (#emacs 'off-by-1') in a 'relatively recent git version'.. emacs -q C-x 3 C-x 2 M-x debug-on-entry RET apropos RET M-x apropos RET x RET d RET d RET ..you should see the buffer alternate windows on each step through the code. Thanks, Pete. In GNU Emacs 23.3.1 (i486-slackware-linux-gnu, GTK+ Version 2.24.1) of 2011-03-12 on midas Windowing system distributor `The X.Org Foundation', version 11.0.10899906 configured using `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--program-prefix=' '--program-suffix=' '--mandir=/usr/man' '--infodir=/usr/info' '--enable-static=no' '--enable-shared=yes' '--with-x' '--with-x-toolkit=gtk' '--build=i486-slackware-linux' 'build_alias=i486-slackware-linux' 'CFLAGS=-O2 -march=i486 -mtune=i686'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: C value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x 3 C-x 2 M-x d e b u g - o n - e n t r y a p r o p o s M-x a p r o p o x d d M-x C-g C-] M-x r e p o r t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Loading apropos...done Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Quit Quit Load-path shadows: ./cedet/cedet-ediff hides ./cedet-1.1bzr8044/cedet-ediff ./cedet/cedet-update-version hides ./cedet-1.1bzr8044/cedet-update-version ./cedet/cedet-build hides ./cedet-1.1bzr8044/cedet-build ./cedet/cedet-update-changelog hides ./cedet-1.1bzr8044/cedet-update-changelog /usr/share/emacs/site-lisp/t-mouse hides /usr/share/emacs/23.3/lisp/t-mouse Features: (shadow sort mail-extr message idna sendmail regexp-opt ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view apropos debug tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind font-render-setting gtk x-toolkit x multi-tty emacs) ------------=_1349255642-7054-1-- From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Oct 2012 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "'martin rudalics'" , <8789-done@debbugs.gnu.org> Cc: michael_heerdegen@web.de Received: via spool by 8789-done@debbugs.gnu.org id=D8789.13492806131451 (code D ref 8789); Wed, 03 Oct 2012 16:11:01 +0000 Received: (at 8789-done) by debbugs.gnu.org; 3 Oct 2012 16:10:13 +0000 Received: from localhost ([127.0.0.1]:51539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRWW-0000NL-IN for submit@debbugs.gnu.org; Wed, 03 Oct 2012 12:10:13 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:22035) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJRWL-0000Mb-4j for 8789-done@debbugs.gnu.org; Wed, 03 Oct 2012 12:10:10 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q93G9rSl031011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Oct 2012 16:09:54 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q93G9q8v019655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 16:09:52 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q93G9p9B031338; Wed, 3 Oct 2012 11:09:51 -0500 Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 09:09:51 -0700 From: "Drew Adams" References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de><504B4940.9000809@gmx.at> <506C01A9.1080406@gmx.at> Date: Wed, 3 Oct 2012 09:09:50 -0700 Message-ID: <8F8D477C739C41D799013DEF29F7A13A@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <506C01A9.1080406@gmx.at> Thread-Index: Ac2hR2APoIcbpVZ2RsGGlWcv3VC0/gAOPr7Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > I now checked in a fix for this in revision 109937 on trunk. > > Bug closed. For related problems that emerged in the discussion > please submit a new bug report. Confirming that the original bug seems fixed. Thanks for making *Backtrace* once again usable with my separate-frame setup. It's now (finally!) back to working just as well as it did for Emacs 20-22. And that's saying something. The frame stays where I put it: same size and location. And the frame is not deleted and re-created at each `d' or `c' I hit. Dunno what your fix was, but thank you. [FWIW, I do get crashes sometimes in the debugger now (e.g. using C-g or C-]), but I expect that is unrelated. I have been getting lots of crashes with recent dev versions. I cannot submit a helpful gdb backtrace according to Eli, so we'll just have to see if someone else reports such crashes.] From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Oct 2012 07:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.135063331619631 (code B ref 8789); Fri, 19 Oct 2012 07:56:02 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Oct 2012 07:55:16 +0000 Received: from localhost ([127.0.0.1]:50968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TP7QK-00056Z-Fo for submit@debbugs.gnu.org; Fri, 19 Oct 2012 03:55:16 -0400 Received: from mout.web.de ([212.227.17.11]:51445) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TP7QH-00056J-RJ for 8789@debbugs.gnu.org; Fri, 19 Oct 2012 03:55:15 -0400 Received: from drachen.dragon ([82.113.121.45]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LpwMZ-1SvqKL1crn-00fWfh; Fri, 19 Oct 2012 09:53:39 +0200 From: Michael Heerdegen References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <5050AF52.5020804@gmx.at> Date: Fri, 19 Oct 2012 09:53:53 +0200 In-Reply-To: <5050AF52.5020804@gmx.at> (martin rudalics's message of "Wed, 12 Sep 2012 17:50:42 +0200") Message-ID: <876266lwxa.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V02:K0:ifaE0cVFjEzu6e28J0KDfXVONsmyaEI8YqLDVDDfk5f LQDAqj1VZLQBq5ijsMN2iMRfi23uSC9jg1ALz9ZJ0g8cs7u9Fl WQ4JsxiAYmSJ1xL2GfXGz4ssHrPJqBzm0AoKPM7r3HHJu/lLwp 42SoLfG5TonEkUTYtMcInz/b+GN2T+sS86OlwwjwOWUaxy/S7R S2ODWNCvbHsd0PYPT9JrOhr0ZP+W/oLiugHfis/tM0= X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.4 (/) Hello Martin, > > Only one wish remains: it is not possible to resize the height of the > > window displaying the *Backtrace* buffer durably. When I resize it with > > the mouse in emacs -Q, this is undone when I hit d in the debugger. It > > would be cool if the size of the window could be changed durably. > > I committed a fix. Please try it. Sorry - but I don't see any difference to what I wrote at this time. I use "GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)\n of 2012-10-18 on dex, modified by Debian" now, so your fix should definitely be included. But neither does it work with my setup, nor with emacs -Q. I see the same behavior as before. Michael. From unknown Tue Jun 24 22:39:01 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Oct 2012 10:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 8789@debbugs.gnu.org Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.135064108531071 (code B ref 8789); Fri, 19 Oct 2012 10:05:01 +0000 Received: (at 8789) by debbugs.gnu.org; 19 Oct 2012 10:04:45 +0000 Received: from localhost ([127.0.0.1]:51117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TP9Rc-000856-V0 for submit@debbugs.gnu.org; Fri, 19 Oct 2012 06:04:45 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:46416) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TP9Rb-00084u-Eu for 8789@debbugs.gnu.org; Fri, 19 Oct 2012 06:04:44 -0400 Received: (qmail invoked by alias); 19 Oct 2012 10:02:11 -0000 Received: from 62-47-36-179.adsl.highway.telekom.at (EHLO [62.47.36.179]) [62.47.36.179] by mail.gmx.net (mp012) with SMTP; 19 Oct 2012 12:02:11 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+wR/1Fnh2wC7Ff5IwWvFXXAD5+ZO+Ay4OoxO72ox W3dAVgdS/2e8z7 Message-ID: <5081251C.50706@gmx.at> Date: Fri, 19 Oct 2012 12:02:04 +0200 From: martin rudalics MIME-Version: 1.0 References: <4DE8DF63.5050405@gmx.at> <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <5050AF52.5020804@gmx.at> <876266lwxa.fsf@web.de> In-Reply-To: <876266lwxa.fsf@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >>> Only one wish remains: it is not possible to resize the height of the >>> window displaying the *Backtrace* buffer durably. When I resize it with >>> the mouse in emacs -Q, this is undone when I hit d in the debugger. It >>> would be cool if the size of the window could be changed durably. >> I committed a fix. Please try it. > > Sorry - but I don't see any difference to what I wrote at this time. I > use "GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)\n of > 2012-10-18 on dex, modified by Debian" now, so your fix should > definitely be included. But neither does it work with my setup, nor > with emacs -Q. I see the same behavior as before. It should have worked from 2012-09-12 until 2012-10-03 but apparently you never tried in that period ;-) Anyway, it should now work again. Please try. Thanks, martin