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

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

bug#13336: [External] : Re: bug#13336: `next-frame' should not choose th


From: martin rudalics
Subject: bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
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





reply via email to

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