[Top][All Lists]

[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
> (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]