[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8789: 23.3; debug backtrace buffer changes window on step-through
From: |
martin rudalics |
Subject: |
bug#8789: 23.3; debug backtrace buffer changes window on step-through |
Date: |
Fri, 17 Feb 2012 10:58:34 +0100 |
> 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
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/02/09
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Stefan Monnier, 2012/02/09
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/02/10
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/15
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Stefan Monnier, 2012/02/15
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/16
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Stefan Monnier, 2012/02/16
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/16
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/02/16
- bug#8789: 23.3; debug backtrace buffer changes window on step-through,
martin rudalics <=
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/24
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/02/28
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/29
bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/02/09