[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: |
Wed, 25 Aug 2021 09:48:29 +0200 |
> I could add a `*Backtrace*' entry to my value of
> `special-display-buffer-names', yes, and duplicate the
> parameters of `special-display-regexps' but also add
> the kludge to work around this bug.
What would you have to "duplicate" here?
> Is that necessary? I was guessing it would be OK
> (and reasonable) to use `after-make-frame-functions'.
Using `after-make-frame-functions' requires a certain knowledge of
Elisp.
>> why on earth don't you use the FRAME-PARAMETERS idiom?
>
> It's not clear to me what idiom you have in mind.
From the doc-string of `special-display-regexps':
Alternatively, an element of this list can be specified as
(REGEXP FRAME-PARAMETERS), where REGEXP is a regexp as above and
FRAME-PARAMETERS an alist of (PARAMETER . VALUE) pairs.
‘special-display-popup-frame’ will then interpret these pairs as
frame parameters when creating a special frame for a buffer whose
name matches REGEXP, overriding the corresponding values from
‘special-display-frame-alist’.
>> > 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).
>
> I see. How would I do that? I don't control how or
> when the frame gets created.
Which means that you have to deal with a situation handled by
`special-display-regexps' once and `display-buffer-alist' now.
>> If you insist on using `after-make-frame-functions',
>> the following should work.
>
> I don't insist. I was trying to interpret what you
> suggested. Should I not use `after-make-frame-functions'
> for some reason (why)?
Because using `after-make-frame-functions' requires a certain knowledge
of Elisp.
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, 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/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