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

[Drew Adams]

>  > (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

Why does that matter here?  I want the frame attributes
to be the same for all buffers whose names match that
regexp.  That is, I would want that, except I apparently
need to add a special frame parameter for `*Backtrace*',
since this bug isn't getting fixed.

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.

Is that necessary?  I was guessing it would be OK
(and reasonable) to use `after-make-frame-functions'.

> why on earth don't you use the FRAME-PARAMETERS idiom?

It's not clear to me what idiom you have in mind.

>  > 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.

>  > 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.

I don't insist.  I was trying to interpret what you
suggested.  Should I not use `after-make-frame-functions'
for some reason (why)?

> (when (equal (buffer-name
>                    (window-buffer (frame-selected-window frame)))
>              "*Backtrace*")

I see.  That makes sense, and it seems to work.
Thank you!

>  > 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.

OK.

With other things, besides frame parameters, the debugger
keeps separate the local, *Backtrace* context and the
outside context - the overal context minus the *Backtrace*
context.  The debugger does its best to keep out of what
is being evaluated/used by Emacs.  That can't be done
perfectly, of course.

E.g., you can evaluate a sexp in the context of *Backtrace*
using `M-:' or whatever, or you can evaluate it in the
outside (non-debugger) context using `e'.  Frame parameters
seem to "break" that design.  But I won't argue the point
further, and I'm no expert on the debugger.