[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
- bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Lars Ingebrigtsen, 2021/08/23
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/23
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, martin rudalics, 2021/08/23
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/23
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, martin rudalics, 2021/08/24
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/24
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging,
martin rudalics <=
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/24
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, martin rudalics, 2021/08/25
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/25
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, martin rudalics, 2021/08/25
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, Drew Adams, 2021/08/25
- bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging, martin rudalics, 2021/08/26