unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.)





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