Subject: bug#12921: 24.2.50; resizing backtrace buffer not persistent (again)

From: martin rudalics <[email-masked]>
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 <[email-masked]>?  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