* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
@ 2014-06-30 10:11 Toomas Rosin
2014-06-30 16:00 ` Michael Heerdegen
0 siblings, 1 reply; 6+ messages in thread
From: Toomas Rosin @ 2014-06-30 10:11 UTC (permalink / raw)
To: 17882
Hi!
Michael Heerdegen's reply to my help request
(<http://lists.gnu.org/archive/html/help-gnu-emacs/2014-06/msg00370.html>)
says it all:
> > I have an Emacs session running for about three weeks now. A couple
> > of days ago, a strange phenomenon started to occur: each time I do
> > something which invokes the debugger (e.g., do a `yank-pop' without a
> > preceding `yank'), the backtrace buffer appears always in one and the
> > same frame (instead of in the frame from which I issued the offending
> > command), which is especially annoying when I happen to work in
> > another frame, on another desktop (which in fact means almost always).
> > (I'm working under KDE.) What could be the matter?
>
> AFAICT, this behavior is in general not unintended. In prior Emacs
> versions, there was a problem that when you hit e.g. d d ... in the
> debugger, the backtrace buffer sometimes was displayed in another window
> for every time you hit d.
>
> What you see is probably an annoying consequence of the related fix.
> I suggest to make a bug report.
>
> > Is there a way to
> > get the normal behaviour back without exiting Emacs and without
> > closing the frame in which the backtrace buffer now always appears?
>
> Try evaluating (setq debugger-previous-window nil).
>
>
> Michael.
I can only add to this that Michael's suggestion about
`debugger-previous-window' worked fine.
Best regards,
T.
----------------------------------------------------------------
In GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.22)
of 2014-05-25 on toomas
Windowing system distributor `The X.Org Foundation', version 11.0.11500000
Configured using:
`configure '--prefix=/usr' '--with-gif=no' '--localstatedir=/var''
Important settings:
value of $LC_COLLATE: C
value of $LANG: et_EE.UTF-8
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: any
Minor modes in effect:
semantic-minor-modes-format: ((:eval (if (or semantic-highlight-edits-mode semantic-show-unmatched-syntax-mode) S)))
gud-tooltip-mode: t
shell-dirtrack-mode: t
display-time-mode: t
desktop-save-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
auto-fill-function: do-auto-fill
Load-path shadows:
None found.
Features:
(shadow mail-extr emacsbug message cl-macs rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
sgml-mode dired css-mode sort conf-mode perl-mode jka-compr pp skeleton
srecode/srt-mode semantic/analyze semantic/sort semantic/scope
semantic/analyze/fcn semantic/db gv semantic/format ezimage
srecode/template srecode/srt-wy semantic/wisent semantic/wisent/wisent
semantic/ctxt srecode/ctxt semantic/tag-ls semantic/find srecode/compile
srecode/dictionary srecode/table srecode eieio-base semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw eieio
mode-local cedet edebug org-wl org-w3m org-vm org-rmail org-mhe org-mew
org-irc org-jsinfo org-infojs org-html org-info org-gnus gnus-util
org-docview org-bibtex bibtex org-bbdb mule-diag cus-edit wid-edit
cus-start cus-load etags goto-addr thingatpt view ses unsafep iso-transl
repeat apropos dabbrev two-column rect misearch multi-isearch debug
latexenc mule-util sh-script smie executable gud tex-mode compile shell
make-mode time desktop quail help-mode derived cl org-exp ob-exp
org-exp-blocks org-agenda org byte-opt warnings bytecomp byte-compile
cconv ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint
ob-keys org-pcomplete pcomplete comint ansi-color ring org-list
org-faces org-entities noutline outline easy-mmode org-version
ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec
find-func cal-menu easymenu calendar cal-loaddefs edmacro kmacro advice
help-fns cl-lib advice-preload time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar 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 minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
2014-06-30 10:11 bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame Toomas Rosin
@ 2014-06-30 16:00 ` Michael Heerdegen
2017-10-13 3:02 ` Noam Postavsky
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2014-06-30 16:00 UTC (permalink / raw)
To: Toomas Rosin; +Cc: 17882
Toomas Rosin <toomas@rosin.ee> writes:
> > What you see is probably an annoying consequence of the related fix.
> > I suggest to make a bug report.
Thanks, Toomas.
I think the debugger is now too strict about reusing the last used
window. `debug` prefers the remembered `debugger-previous-window`.
AFAIK, this variable is never unset, so the debugger tries to reuse the
last used window even when the last debugging session was over for
hours. This is a problem when that window is still existing, but not
"reachable" (say, on another display).
This is the relevant code in `debug`:
(pop-to-buffer
debugger-buffer
`((display-buffer-reuse-window
display-buffer-in-previous-window)
. (,(when debugger-previous-window
`(previous-window . ,debugger-previous-window)))))
Should we add a test whether `debugger-previous-window`s frame fulfills
(lambda (frame) (eq t (frame-visible-p frame))) ?
Thanks,
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
2014-06-30 16:00 ` Michael Heerdegen
@ 2017-10-13 3:02 ` Noam Postavsky
2017-10-13 10:10 ` Michael Heerdegen
2017-10-14 8:35 ` martin rudalics
0 siblings, 2 replies; 6+ messages in thread
From: Noam Postavsky @ 2017-10-13 3:02 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Toomas Rosin, 17882
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
tags 17882 + patch
quit
Michael Heerdegen <michael_heerdegen@web.de> writes:
> I think the debugger is now too strict about reusing the last used
> window. `debug` prefers the remembered `debugger-previous-window`.
> AFAIK, this variable is never unset, so the debugger tries to reuse the
> last used window even when the last debugging session was over for
> hours.
How about just unsetting the debugger-previous-window when the session
is over, we already know this info from the `debugger-will-be-back'
variable:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1153 bytes --]
From bdeae0b9afcccc11d43d46089ea4648a68b709cd Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Thu, 12 Oct 2017 22:59:53 -0400
Subject: [PATCH v1] Don't remember old debugger window (Bug#17882)
* lisp/emacs-lisp/debug.el (debug): Unset debugger-previous-window
when `debugger-will-be-back' is nil.
---
lisp/emacs-lisp/debug.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index 0247179a84..6c754615b0 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -253,7 +253,9 @@ debug
;; Unshow debugger-buffer.
(quit-restore-window debugger-window debugger-bury-or-kill)
;; Restore current buffer (Bug#12502).
- (set-buffer debugger-old-buffer))))
+ (set-buffer debugger-old-buffer)))
+ ;; Forget debugger window, it won't be back (Bug#17882).
+ (setq debugger-previous-window nil))
;; Restore previous state of debugger-buffer in case we were
;; in a recursive invocation of the debugger, otherwise just
;; erase the buffer and put it into fundamental mode.
--
2.11.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
2017-10-13 3:02 ` Noam Postavsky
@ 2017-10-13 10:10 ` Michael Heerdegen
2017-10-15 18:24 ` Noam Postavsky
2017-10-14 8:35 ` martin rudalics
1 sibling, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2017-10-13 10:10 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Toomas Rosin, 17882
Noam Postavsky <npostavs@users.sourceforge.net> writes:
> How about just unsetting the debugger-previous-window when the session
> is over, we already know this info from the `debugger-will-be-back'
> variable:
Makes sense, thanks. Seems to work ok here.
Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
2017-10-13 3:02 ` Noam Postavsky
2017-10-13 10:10 ` Michael Heerdegen
@ 2017-10-14 8:35 ` martin rudalics
1 sibling, 0 replies; 6+ messages in thread
From: martin rudalics @ 2017-10-14 8:35 UTC (permalink / raw)
To: Noam Postavsky, Michael Heerdegen; +Cc: Toomas Rosin, 17882
> How about just unsetting the debugger-previous-window when the session
> is over, we already know this info from the `debugger-will-be-back'
> variable:
Check it in. I doubt we'll get any complaints for this.
martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame
2017-10-13 10:10 ` Michael Heerdegen
@ 2017-10-15 18:24 ` Noam Postavsky
0 siblings, 0 replies; 6+ messages in thread
From: Noam Postavsky @ 2017-10-15 18:24 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: Toomas Rosin, 17882
tags 17882 fixed
close 17882 26.1
quit
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Noam Postavsky <npostavs@users.sourceforge.net> writes:
>
>> How about just unsetting the debugger-previous-window when the session
>> is over, we already know this info from the `debugger-will-be-back'
>> variable:
>
> Makes sense, thanks. Seems to work ok here.
>
> Michael.
martin rudalics <rudalics@gmx.at> writes:
>
> Check it in. I doubt we'll get any complaints for this.
>
> martin
Pushed to emacs-26.
[1: 51615a8082]: 2017-10-15 13:58:45 -0400
Don't remember old debugger window (Bug#17882)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=51615a808236058ac732a5eaba239874d56fdd10
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-10-15 18:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-30 10:11 bug#17882: 24.3; *Backtrace* buffer appearing in the wrong frame Toomas Rosin
2014-06-30 16:00 ` Michael Heerdegen
2017-10-13 3:02 ` Noam Postavsky
2017-10-13 10:10 ` Michael Heerdegen
2017-10-15 18:24 ` Noam Postavsky
2017-10-14 8:35 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).