From: Drew Adams <drew.adams@oracle.com>
To: npostavs@users.sourceforge.net
Cc: 13336@debbugs.gnu.org
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) [thread overview]
Message-ID: <796316f7-38a5-4927-88df-96b8b90c3cea@default> (raw)
In-Reply-To: <87sho1qcp9.fsf@users.sourceforge.net>
> 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.)
next prev parent reply other threads:[~2017-01-30 14:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-02 18:13 bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked Drew Adams
2017-01-30 6:33 ` npostavs
2017-01-30 14:32 ` Drew Adams [this message]
2017-01-31 3:22 ` npostavs
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
2021-08-23 15:20 ` bug#13336: [External] : " Drew Adams
2021-08-23 16:06 ` martin rudalics
2021-08-23 17:41 ` Drew Adams
2021-08-24 9:41 ` martin rudalics
2021-08-24 15:49 ` Drew Adams
2021-08-24 17:41 ` martin rudalics
2021-08-24 20:02 ` Drew Adams
2021-08-25 7:48 ` martin rudalics
2021-08-25 15:27 ` Drew Adams
2021-08-25 19:41 ` martin rudalics
2021-08-25 20:23 ` Drew Adams
2021-08-26 7:53 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=796316f7-38a5-4927-88df-96b8b90c3cea@default \
--to=drew.adams@oracle.com \
--cc=13336@debbugs.gnu.org \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).