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

[martin rudalics]

> 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