bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtr


From: Drew Adams
Subject: bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
Date: Mon, 30 Jan 2017 06:32:31 -0800 (PST)

> retitle 13336 `other-frame' should not choose a frame (e.g. *Backtrace*)
> that did not exist when it was invoked
> severity 13336 wishlist
> quit
> 
> > 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
> 
> I suppose you meant `other-frame' here (next-frame is a C
> function) and in the title.

No, not really.  As you see from the backtrace, it is
`next-frame' that returns frame *Backtrace*, which is
inappropriate.

FWIW, I have code that calls `next-frame' and does not use
`other-frame'.  This is not an `other-frame' bug (except
indirectly, because it calls `next-frame', which is bugged).
The bug is with `next-frame'.  Please see the backtrace.

> > 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 again suppose you mean `other-frame' here, otherwise I would say it's
> not a bug, since the the *Backtrace* frame does exist by the time
> `next-frame' is called.

See above.

At least in the case of *Backtrace*, which is perhaps a special
case, it makes no difference whether the frame exists by the
time `next-frame' is called.  Backtrace acts specially: it does
not take its own context into account, but instead reflects the
state of the rest of Emacs.  The debugger should not return the
*Backtrace* frame.

> By the way, from your backtrace it looks like you did debug-on-entry on
> `other-frame', but in that case there's no way for it to "snapshot" the
> list of existing frames "before" the call, since you've stopped in the
> debugger before any of its code is executed.  It's only possible to fix
> the case where you stop only later on next-frame.

No, I did `M-x debug-on-entry next-frame'.  The backtrace opens
at the call to `next-frame', but it shows the trace back to
the interactive call of `other-frame'.

I just now reproduced the problem, using Emacs 24.3, starting
from emacs -Q.  I assume that it can also be reproduced with
Emacs 25.

(I believe I did mean `C-x 5 o', not `C-x o', in the recipe,
however.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]