bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging

[Drew Adams <drew.adams@oracle.com>]

> > Set `special-display-regexps' or other so that `*Backtrace*' gets
> > displayed in its own (special-display) frame.
> >
> > Evaluate the source code for `next-frame', then
> > M-x debug-on-entry next-frame, then C-x o.
> >
> > When stepping through the debugger, the next frame should never be
> > *Backtrace* (unless a *Backtrace* frame existed before invoking `next
> > frame'), but it can be.  This is a bug IMO.
> 
> I don't think so.  There's a gazillion things you can do while
> edebugging that will make stepping through the code not behave like it
> would otherwise (moving frames to different terminals, closing frames,
> opening new frames, etc).  Adding something special here for *Backtrace*
> would just be confusing, so I'm closing this bug report.

There is plenty of special treatment for *Backtrace*,
involving the current buffer, selected window, frame,
vars, etc.  Otherwise it wouldn't work at all.

Trying to examine/debug the execution of code that
involves the use of `next-frame' etc. requires that
a separate *Backtrace* frame not confuse things, just
as the debugger tries to keep other *Backtrace* state
out of the displayed debugger evaluation.

(FWIW, the recipe does not use `edebug', though I
doubt that's important here.  It uses `debug-on-entry',
which I think just uses `debug', not `edebug'.)

The recipe didn't include doing any other things,
let alone a gazillion of them.  But the recipe
incorrectly said `C-x o' instead of `C-x 5 o', which
is bound to `other-frame'.

And, as the backtrace in the bug report showed, the
recipe should have said to evaluate the source def of
`other-frame', not `next-frame' (which is defined in
C), but this too really isn't necessary.

It's pretty simple, really:
___

emacs -Q
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
M-x debug-on-entry other-frame
___

In Emacs 27.2 (and older):

Debugger entered--returning value: #<frame *Backtrace* 00000000086fc510>
  next-frame(#<frame *scratch* 00000000049a0930>)
* (setq frame (next-frame frame))
* (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (next-frame frame))) (setq arg (1- arg)))
* (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame))
* (closure (frame-initial-frame-alist t) (arg) "Select the ARGth different visible frame on curren..." (interactive "p") (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame)))(1)
* apply((closure (frame-initial-frame-alist t) (arg) "Select the ARGth different visible frame on curren..." (interactive "p") (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame))) 1)
* other-frame(1)
  funcall-interactively(other-frame 1)
  call-interactively(other-frame nil nil)
  command-execute(other-frame)
___

Such behavior makes it pretty much impossible to
follow code that itself invokes `next-frame'.
That's the point.

We jump through a number of hoops to ensure that
the debugger state and its own display don't
interfere with the state that we're trying to
show of the code being debugged.

It's not possible to do that completely, of course.
But this is apparently just another case of Emacs
not having paid enough attention to using separate
frames with dedicated windows.  An oversight, I
expect.