GNU bug report logs - #12921
24.2.50; resizing backtrace buffer not persistent (again)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12921 in the body.
You can then email your comments to 12921 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.50; resizing backtrace buffer not persistent (again)
Date: Sun, 18 Nov 2012 04:14:46 +0100

Hi,

some time ago, Martin Rudalics had written a patch so that when the
window displaying *Backtrace* is resized, the effect was persistent.
This works in general, but not in every case:

In emacs -Q, type M-x debug.  The frame gets split vertically.  The
window below displays *Backtrace*.  But dragging the mode-line in the
middle doesn't resize the window persistently when you step in the
debugger.

Resizing is performed here in these lines of `debug':

      (if (eq debugger-previous-window debugger-window)
	  (when debugger-jumping-flag
	    ;; Try to restore previous height of debugger
	    ;; window.
	    (condition-case nil
		(window-resize
		 debugger-window
		 (- debugger-previous-window-height
		    (window-total-size debugger-window)))
	      (error nil)))
	(setq debugger-previous-window debugger-window))

However, in the above case, (eq debugger-previous-window
debugger-window) is never true, probably because the vertical splitting
into two windows is performed and undone on each step.

Would it be harmful to perform resizing unconditionally?  This fixes
the problem for me, but I'm not sure if it could be harmful in certain
situations.  OTOH, if the window was created newly when the debugger had
been reentered, we already changed the window layout, so forcing a
certain size should not be dangerous, in general.


Regards,

Michael.



In GNU Emacs 24.2.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
 of 2012-11-17 on drachen
Bzr revision: eliz <at> gnu.org-20121117185106-96kkgf04rybaukwo
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
System Description:	Debian GNU/Linux testing (wheezy)

Message #8 received at 12921 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: michael_heerdegen <at> web.de
Cc: 12921 <at> debbugs.gnu.org
Subject: Re: bug#12921: 24.2.50; resizing backtrace buffer not persistent
	(again)
Date: Sun, 18 Nov 2012 12:36:52 +0100

> In emacs -Q, type M-x debug.  The frame gets split vertically.  The
> window below displays *Backtrace*.  But dragging the mode-line in the
> middle doesn't resize the window persistently when you step in the
> debugger.
>
> Resizing is performed here in these lines of `debug':
>
>       (if (eq debugger-previous-window debugger-window)
> 	  (when debugger-jumping-flag
> 	    ;; Try to restore previous height of debugger
> 	    ;; window.
> 	    (condition-case nil
> 		(window-resize
> 		 debugger-window
> 		 (- debugger-previous-window-height
> 		    (window-total-size debugger-window)))
> 	      (error nil)))
> 	(setq debugger-previous-window debugger-window))
>
> However, in the above case, (eq debugger-previous-window
> debugger-window) is never true, probably because the vertical splitting
> into two windows is performed and undone on each step.
>
> Would it be harmful to perform resizing unconditionally?  This fixes
> the problem for me, but I'm not sure if it could be harmful in certain
> situations.  OTOH, if the window was created newly when the debugger had
> been reentered, we already changed the window layout, so forcing a
> certain size should not be dangerous, in general.

You mean a patch like the below?  Note that I have no idea how the
debugger should behave when the window layout is changed by the debugged
code.

martin


*** lisp/emacs-lisp/debug.el	2012-11-11 01:16:25 +0000
--- lisp/emacs-lisp/debug.el	2012-11-18 09:55:27 +0000
***************
*** 228,247 ****
  	       debugger-buffer
  	       `((display-buffer-reuse-window
  		  display-buffer-in-previous-window)
! 		  . (,(when debugger-previous-window
! 			`(previous-window . ,debugger-previous-window)))))
  	      (setq debugger-window (selected-window))
! 	      (if (eq debugger-previous-window debugger-window)
! 		  (when debugger-jumping-flag
! 		    ;; Try to restore previous height of debugger
! 		    ;; window.
! 		    (condition-case nil
! 			(window-resize
! 			 debugger-window
! 			 (- debugger-previous-window-height
! 			    (window-total-size debugger-window)))
! 		      (error nil)))
! 		(setq debugger-previous-window debugger-window))
  	      (debugger-mode)
  	      (debugger-setup-buffer debugger-args)
  	      (when noninteractive
--- 228,246 ----
  	       debugger-buffer
  	       `((display-buffer-reuse-window
  		  display-buffer-in-previous-window)
! 		 . (,(when debugger-previous-window
! 		       `(previous-window . ,debugger-previous-window)))))
  	      (setq debugger-window (selected-window))
! 	      (when debugger-jumping-flag
! 		;; Try to restore previous height of debugger
! 		;; window.
! 		(condition-case nil
! 		    (window-resize
! 		     debugger-window
! 		     (- debugger-previous-window-height
! 			(window-total-size debugger-window)))
! 		  (error nil)))
! 	      (setq debugger-previous-window debugger-window)
  	      (debugger-mode)
  	      (debugger-setup-buffer debugger-args)
  	      (when noninteractive

Message #11 received at 12921 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12921 <at> debbugs.gnu.org
Subject: Re: bug#12921: 24.2.50;
	resizing backtrace buffer not persistent (again)
Date: Mon, 19 Nov 2012 01:18:38 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> You mean a patch like the below?

Exactly.  Objections against applying?

> Note that I have no idea how the debugger should behave when the
> window layout is changed by the debugged code.

Dunno if it's worth trying to optimize the code for that.  If I want to
debug such code, I can just use a different frame for the debugger.

Martin, if you have some time, could you maybe also have a look at what
I wrote about 10025 in <87txsn4pjk.fsf <at> web.de>?  If I understood things
right and we are lucky, the number of debugger frames in the backtrace
has just decreased by 1 due to some change in the past, and the only
thing to do is to decrease the appropriate hardcoded numbers in `debug'
as well.  By "debugger frames" I mean the frames belonging to the code
that is added to the debugged functions in order to instrument them.
Note that you must recompile debug.el and load the compiled code to see
the right behavior, because the number of debugger frames is different
if the debugger is run as uncompiled code.


Regards, thanks,

Michael.

Message #14 received at 12921 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 12921 <at> debbugs.gnu.org
Subject: Re: bug#12921: 24.2.50; resizing backtrace buffer not persistent
	(again)
Date: Mon, 19 Nov 2012 09:01:54 +0100

>> You mean a patch like the below?
>
> Exactly.  Objections against applying?

I can do it on the trunk, once it has reached a fairly stable state
again.  If someone complains, we can always customize it.

>> Note that I have no idea how the debugger should behave when the
>> window layout is changed by the debugged code.
>
> Dunno if it's worth trying to optimize the code for that.  If I want to
> debug such code, I can just use a different frame for the debugger.

OK.

> Martin, if you have some time, could you maybe also have a look at what
> I wrote about 10025 in <87txsn4pjk.fsf <at> web.de>?  If I understood things
> right and we are lucky, the number of debugger frames in the backtrace
> has just decreased by 1 due to some change in the past, and the only
> thing to do is to decrease the appropriate hardcoded numbers in `debug'
> as well.  By "debugger frames" I mean the frames belonging to the code
> that is added to the debugged functions in order to instrument them.
> Note that you must recompile debug.el and load the compiled code to see
> the right behavior, because the number of debugger frames is different
> if the debugger is run as uncompiled code.

Never using `debug-on-entry', I'm hardly qualified to comment on this.
Someone would simply have to find the change that broke it.  All I can
say is that it apparently worked for a build in 2009.  Could you try
bisecting?

I also dont understand whether and how bugs #6209 and #9462 are related
to the current issue (IIUC #6209 was never fixed and I don't understand
why it was archived).

martin

Message #17 received at 12921 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 12921 <at> debbugs.gnu.org
Subject: Re: bug#12921: 24.2.50; resizing backtrace buffer not persistent
 (again)
Date: Tue, 25 Aug 2020 14:07:03 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>>> You mean a patch like the below?
>>
>> Exactly.  Objections against applying?
>
> I can do it on the trunk, once it has reached a fairly stable state
> again.  If someone complains, we can always customize it.

It looks like this patch was never applied?  Has the reported problem
been fixed in a different way in the years that have passed since this
bug was filed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 12921 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 12921 <at> debbugs.gnu.org
Subject: Re: bug#12921: 24.2.50; resizing backtrace buffer not persistent
 (again)
Date: Mon, 06 Sep 2021 12:48:22 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> It looks like this patch was never applied?  Has the reported problem
> been fixed in a different way in the years that have passed since this
> bug was filed?

The problem is still present in Emacs 28, and Martin's patch still fixes
the problem, so I've now pushed it to the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.