bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Wed, 19 Sep 2012 19:10:52 +0200

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





reply via email to

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