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

[martin rudalics <rudalics@gmx.at>]

 > 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