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

[martin rudalics]

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