* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
@ 2012-11-18 3:14 Michael Heerdegen
2012-11-18 11:36 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2012-11-18 3:14 UTC (permalink / raw)
To: 12921
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@gnu.org-20121117185106-96kkgf04rybaukwo
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
System Description: Debian GNU/Linux testing (wheezy)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
2012-11-18 3:14 bug#12921: 24.2.50; resizing backtrace buffer not persistent (again) Michael Heerdegen
@ 2012-11-18 11:36 ` martin rudalics
2012-11-19 0:18 ` Michael Heerdegen
0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2012-11-18 11:36 UTC (permalink / raw)
To: michael_heerdegen; +Cc: 12921
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
2012-11-18 11:36 ` martin rudalics
@ 2012-11-19 0:18 ` Michael Heerdegen
2012-11-19 8:01 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Michael Heerdegen @ 2012-11-19 0:18 UTC (permalink / raw)
To: martin rudalics; +Cc: 12921
martin rudalics <rudalics@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@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
2012-11-19 0:18 ` Michael Heerdegen
@ 2012-11-19 8:01 ` martin rudalics
2020-08-25 12:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2012-11-19 8:01 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 12921
>> 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@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
2012-11-19 8:01 ` martin rudalics
@ 2020-08-25 12:07 ` Lars Ingebrigtsen
2021-09-06 10:48 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-25 12:07 UTC (permalink / raw)
To: martin rudalics; +Cc: Michael Heerdegen, 12921
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)
2020-08-25 12:07 ` Lars Ingebrigtsen
@ 2021-09-06 10:48 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-06 10:48 UTC (permalink / raw)
To: martin rudalics; +Cc: Michael Heerdegen, 12921
Lars Ingebrigtsen <larsi@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-06 10:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-18 3:14 bug#12921: 24.2.50; resizing backtrace buffer not persistent (again) Michael Heerdegen
2012-11-18 11:36 ` martin rudalics
2012-11-19 0:18 ` Michael Heerdegen
2012-11-19 8:01 ` martin rudalics
2020-08-25 12:07 ` Lars Ingebrigtsen
2021-09-06 10:48 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.