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

From: martin rudalics <[email-masked]>
Date: Tue, 24 Aug 2021 19:41:18 +0200

> I did this:
 >
 > (when (if (fboundp 'display-graphic-p)
 >            (display-graphic-p)
 >          window-system)
 >    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

If you insist on using the obsolete `special-display-regexps', then why
on earth don't you use a buffer name with it and why on earth don't you
use the FRAME-PARAMETERS idiom?

 >    (when (> emacs-major-version 25)
 >      (defun backtrace-no-other-frame (frame)
 >        (when (equal (frame-parameter frame 'name)
 >                     "*Backtrace*")
 >          (set-frame-parameter frame 'no-other-frame t)))
 >      (add-hook 'after-make-frame-functions
 >                'backtrace-no-other-frame)))
 >
 > Debugging a bit shows that frame parameter `name' for
 > the *Backtrace* frame is indeed "*Backtrace*",

Not at the time `after-make-frame-functions' gets called (unless you
specified a name for it).

 > but
 > parameter `no-other-frame' is nil (doesn't get set to
 > `t').  What's more, it looks like (?) function
 > `backtrace-no-other-frame' doesn't even get invoked.
 >
 > What should I be doing instead?  I don't explicitly
 > create frame *Backtrace* myself.  I presumably need
 > to somehow have its `no-other-frame' frame parameter
 > set to `t' whenever it's created.

If you insist on using `after-make-frame-functions', the following
should work.

(defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

(defun backtrace-no-other-frame (frame)
   (when (equal (buffer-name
		(window-buffer (frame-selected-window frame)))
                "*Backtrace*")
     (set-frame-parameter frame 'no-other-frame t)))

(add-hook 'after-make-frame-functions
           'backtrace-no-other-frame)

 > Beyond finding a solution for myself: I guess you too
 > consider that this should not be fixed generally, i.e.,
 > that frame *Backtrace* should be allowed to be another
 > frame's `next-frame'.  If so, I'm curious as to why.

I see no general rule here.  When debugging window management problems,
a separate frame comes in handy.  OTOH when debugging frame management
problems, a window on an existing frame might be preferable.

martin