* bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
@ 2013-01-02 18:13 Drew Adams
2017-01-30 6:33 ` npostavs
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
0 siblings, 2 replies; 17+ messages in thread
From: Drew Adams @ 2013-01-02 18:13 UTC (permalink / raw)
To: 13336
Set `special-display-regexps' or other so that `*Backtrace*' gets
displayed in its own (special-display) frame.
Evaluate the source code for `next-frame', then
M-x debug-on-entry next-frame, then C-x o.
When stepping through the debugger, the next frame should never be
*Backtrace* (unless a *Backtrace* frame existed before invoking `next
frame'), but it can be. This is a bug IMO.
Debugger entered--returning value: #<frame *Backtrace* 04B01700>
next-frame(#<frame drews-lisp-20 03F49668>)
* (setq frame (next-frame frame))
* (while (> arg 0) (setq frame (next-frame frame)) (while (not (eq
(frame-visible-p frame) t)) (setq frame (next-frame frame))) (setq arg (1-
arg)))
* (let ((frame (selected-frame))) (while (> arg 0) (setq frame (next-frame
frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame (next-frame
frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame
frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame (previous-frame
frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame))
* (lambda (arg) "Select the ARGth different visible frame on current display,
and raise it.\nAll frames are arranged in a cyclic order.\nThis command selects
the frame ARG steps away in that order.\nA negative ARG moves in the opposite
order.\n\nTo make this command work properly, you must tell Emacs\nhow the
system (or the window manager) generally handles\nfocus-switching between
windows. If moving the mouse onto a window\nselects it (gives it focus), set
`focus-follows-mouse' to t.\nOtherwise, that variable should be nil."
(interactive "p") (let ((frame (selected-frame))) (while (> arg 0) (setq frame
(next-frame frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame
(next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame
(previous-frame frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame
(previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus
frame)))(1)
* apply((lambda (arg) "Select the ARGth different visible frame on current
display, and raise it.\nAll frames are arranged in a cyclic order.\nThis command
selects the frame ARG steps away in that order.\nA negative ARG moves in the
opposite order.\n\nTo make this command work properly, you must tell Emacs\nhow
the system (or the window manager) generally handles\nfocus-switching between
windows. If moving the mouse onto a window\nselects it (gives it focus), set
`focus-follows-mouse' to t.\nOtherwise, that variable should be nil."
(interactive "p") (let ((frame (selected-frame))) (while (> arg 0) (setq frame
(next-frame frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame
(next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame
(previous-frame frame)) (while (not (eq (frame-visible-p frame) t)) (setq frame
(previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus
frame))) 1)
* other-frame(1)
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2012-12-31 on ODIEONE
Bzr revision: 111388 rudalics@gmx.at-20121231113513-subz2dazg6yjukzh
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
2013-01-02 18:13 bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked Drew Adams
@ 2017-01-30 6:33 ` npostavs
2017-01-30 14:32 ` Drew Adams
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
1 sibling, 1 reply; 17+ messages in thread
From: npostavs @ 2017-01-30 6:33 UTC (permalink / raw)
To: Drew Adams; +Cc: 13336
retitle 13336 `other-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
severity 13336 wishlist
quit
"Drew Adams" <drew.adams@oracle.com> writes:
> Set `special-display-regexps' or other so that `*Backtrace*' gets
> displayed in its own (special-display) frame.
>
> Evaluate the source code for `next-frame', then
I suppose you meant `other-frame' here (next-frame is a C
function) and in the title.
> M-x debug-on-entry next-frame, then C-x o.
>
> When stepping through the debugger, the next frame should never be
> *Backtrace* (unless a *Backtrace* frame existed before invoking `next
> frame'), but it can be. This is a bug IMO.
I again suppose you mean `other-frame' here, otherwise I would say it's
not a bug, since the the *Backtrace* frame does exist by the time
`next-frame' is called.
By the way, from your backtrace it looks like you did debug-on-entry on
`other-frame', but in that case there's no way for it to "snapshot" the
list of existing frames "before" the call, since you've stopped in the
debugger before any of its code is executed. It's only possible to fix
the case where you stop only later on next-frame.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
2017-01-30 6:33 ` npostavs
@ 2017-01-30 14:32 ` Drew Adams
2017-01-31 3:22 ` npostavs
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2017-01-30 14:32 UTC (permalink / raw)
To: npostavs; +Cc: 13336
> retitle 13336 `other-frame' should not choose a frame (e.g. *Backtrace*)
> that did not exist when it was invoked
> severity 13336 wishlist
> quit
>
> > Set `special-display-regexps' or other so that `*Backtrace*' gets
> > displayed in its own (special-display) frame.
> > Evaluate the source code for `next-frame', then
>
> I suppose you meant `other-frame' here (next-frame is a C
> function) and in the title.
No, not really. As you see from the backtrace, it is
`next-frame' that returns frame *Backtrace*, which is
inappropriate.
FWIW, I have code that calls `next-frame' and does not use
`other-frame'. This is not an `other-frame' bug (except
indirectly, because it calls `next-frame', which is bugged).
The bug is with `next-frame'. Please see the backtrace.
> > M-x debug-on-entry next-frame, then C-x o.
> >
> > When stepping through the debugger, the next frame should never be
> > *Backtrace* (unless a *Backtrace* frame existed before invoking `next
> > frame'), but it can be. This is a bug IMO.
>
> I again suppose you mean `other-frame' here, otherwise I would say it's
> not a bug, since the the *Backtrace* frame does exist by the time
> `next-frame' is called.
See above.
At least in the case of *Backtrace*, which is perhaps a special
case, it makes no difference whether the frame exists by the
time `next-frame' is called. Backtrace acts specially: it does
not take its own context into account, but instead reflects the
state of the rest of Emacs. The debugger should not return the
*Backtrace* frame.
> By the way, from your backtrace it looks like you did debug-on-entry on
> `other-frame', but in that case there's no way for it to "snapshot" the
> list of existing frames "before" the call, since you've stopped in the
> debugger before any of its code is executed. It's only possible to fix
> the case where you stop only later on next-frame.
No, I did `M-x debug-on-entry next-frame'. The backtrace opens
at the call to `next-frame', but it shows the trace back to
the interactive call of `other-frame'.
I just now reproduced the problem, using Emacs 24.3, starting
from emacs -Q. I assume that it can also be reproduced with
Emacs 25.
(I believe I did mean `C-x 5 o', not `C-x o', in the recipe,
however.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked
2017-01-30 14:32 ` Drew Adams
@ 2017-01-31 3:22 ` npostavs
0 siblings, 0 replies; 17+ messages in thread
From: npostavs @ 2017-01-31 3:22 UTC (permalink / raw)
To: Drew Adams; +Cc: 13336
retitle 13336 `next-frame' should not choose the *Backtrace* frame while debugging
quit
Drew Adams <drew.adams@oracle.com> writes:
>
> At least in the case of *Backtrace*, which is perhaps a special
> case, it makes no difference whether the frame exists by the
> time `next-frame' is called. Backtrace acts specially: it does
> not take its own context into account, but instead reflects the
> state of the rest of Emacs. The debugger should not return the
> *Backtrace* frame.
Ah okay, a special case for *Backtrace* could make sense. Although I
forsee some tricky edge cases since *Backtrace* is a buffer, not a
frame.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2013-01-02 18:13 bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked Drew Adams
2017-01-30 6:33 ` npostavs
@ 2021-08-23 14:37 ` Lars Ingebrigtsen
2021-08-23 15:20 ` bug#13336: [External] : " Drew Adams
1 sibling, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-23 14:37 UTC (permalink / raw)
To: Drew Adams; +Cc: 13336
"Drew Adams" <drew.adams@oracle.com> writes:
> Set `special-display-regexps' or other so that `*Backtrace*' gets
> displayed in its own (special-display) frame.
>
> Evaluate the source code for `next-frame', then
> M-x debug-on-entry next-frame, then C-x o.
>
> When stepping through the debugger, the next frame should never be
> *Backtrace* (unless a *Backtrace* frame existed before invoking `next
> frame'), but it can be. This is a bug IMO.
I don't think so. There's a gazillion things you can do while
edebugging that will make stepping through the code not behave like it
would otherwise (moving frames to different terminals, closing frames,
opening new frames, etc). Adding something special here for *Backtrace*
would just be confusing, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
@ 2021-08-23 15:20 ` Drew Adams
2021-08-23 16:06 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-23 15:20 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> > Set `special-display-regexps' or other so that `*Backtrace*' gets
> > displayed in its own (special-display) frame.
> >
> > Evaluate the source code for `next-frame', then
> > M-x debug-on-entry next-frame, then C-x o.
> >
> > When stepping through the debugger, the next frame should never be
> > *Backtrace* (unless a *Backtrace* frame existed before invoking `next
> > frame'), but it can be. This is a bug IMO.
>
> I don't think so. There's a gazillion things you can do while
> edebugging that will make stepping through the code not behave like it
> would otherwise (moving frames to different terminals, closing frames,
> opening new frames, etc). Adding something special here for *Backtrace*
> would just be confusing, so I'm closing this bug report.
There is plenty of special treatment for *Backtrace*,
involving the current buffer, selected window, frame,
vars, etc. Otherwise it wouldn't work at all.
Trying to examine/debug the execution of code that
involves the use of `next-frame' etc. requires that
a separate *Backtrace* frame not confuse things, just
as the debugger tries to keep other *Backtrace* state
out of the displayed debugger evaluation.
(FWIW, the recipe does not use `edebug', though I
doubt that's important here. It uses `debug-on-entry',
which I think just uses `debug', not `edebug'.)
The recipe didn't include doing any other things,
let alone a gazillion of them. But the recipe
incorrectly said `C-x o' instead of `C-x 5 o', which
is bound to `other-frame'.
And, as the backtrace in the bug report showed, the
recipe should have said to evaluate the source def of
`other-frame', not `next-frame' (which is defined in
C), but this too really isn't necessary.
It's pretty simple, really:
___
emacs -Q
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))
M-x debug-on-entry other-frame
___
In Emacs 27.2 (and older):
Debugger entered--returning value: #<frame *Backtrace* 00000000086fc510>
next-frame(#<frame *scratch* 00000000049a0930>)
* (setq frame (next-frame frame))
* (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (next-frame frame))) (setq arg (1- arg)))
* (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq (frame-visible-p frame) t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame))
* (closure (frame-initial-frame-alist t) (arg) "Select the ARGth different visible frame on curren..." (interactive "p") (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame)))(1)
* apply((closure (frame-initial-frame-alist t) (arg) "Select the ARGth different visible frame on curren..." (interactive "p") (let ((sframe (selected-frame)) (frame (selected-frame))) (while (> arg 0) (setq frame (next-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (next-frame frame))) (setq arg (1- arg))) (while (< arg 0) (setq frame (previous-frame frame)) (while (and (not (eq frame sframe)) (not (eq ... t))) (setq frame (previous-frame frame))) (setq arg (1+ arg))) (select-frame-set-input-focus frame))) 1)
* other-frame(1)
funcall-interactively(other-frame 1)
call-interactively(other-frame nil nil)
command-execute(other-frame)
___
Such behavior makes it pretty much impossible to
follow code that itself invokes `next-frame'.
That's the point.
We jump through a number of hoops to ensure that
the debugger state and its own display don't
interfere with the state that we're trying to
show of the code being debugged.
It's not possible to do that completely, of course.
But this is apparently just another case of Emacs
not having paid enough attention to using separate
frames with dedicated windows. An oversight, I
expect.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-23 15:20 ` bug#13336: [External] : " Drew Adams
@ 2021-08-23 16:06 ` martin rudalics
2021-08-23 17:41 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2021-08-23 16:06 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> Such behavior makes it pretty much impossible to
> follow code that itself invokes `next-frame'.
> That's the point.
Try giving the *Backtrace* frame a non-nil 'no-other-frame' parameter.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-23 16:06 ` martin rudalics
@ 2021-08-23 17:41 ` Drew Adams
2021-08-24 9:41 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-23 17:41 UTC (permalink / raw)
To: martin rudalics, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> > Such behavior makes it pretty much impossible to
> > follow code that itself invokes `next-frame'.
> > That's the point.
>
> Try giving the *Backtrace* frame a non-nil 'no-other-frame' parameter.
Thanks for that info. Should I be doing that, or
should that happen automatically? What Emacs
releases does that work in (in what releases is
that frame parameter available and effective)?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-23 17:41 ` Drew Adams
@ 2021-08-24 9:41 ` martin rudalics
2021-08-24 15:49 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2021-08-24 9:41 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
>> Try giving the *Backtrace* frame a non-nil 'no-other-frame' parameter.
>
> Thanks for that info. Should I be doing that, or
> should that happen automatically?
It does not happen automatically so you should be doing that.
> What Emacs
> releases does that work in (in what releases is
> that frame parameter available and effective)?
It was added with Emacs 26.1.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-24 9:41 ` martin rudalics
@ 2021-08-24 15:49 ` Drew Adams
2021-08-24 17:41 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-24 15:49 UTC (permalink / raw)
To: martin rudalics, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> >> Try giving the *Backtrace* frame a non-nil 'no-other-frame' parameter.
> >
> > Thanks for that info. Should I be doing that, or
> > should that happen automatically?
>
> It does not happen automatically so you should be doing that.
>
> > What Emacs
> > releases does that work in (in what releases is
> > that frame parameter available and effective)?
>
> It was added with Emacs 26.1.
Thanks. I tried it, but it doesn't seem to work.
I did this:
(when (if (fboundp 'display-graphic-p)
(display-graphic-p)
window-system)
(defconst special-display-regexps '("[ ]?[*][^*]+[*]"))
(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*", 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.
___
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-24 15:49 ` Drew Adams
@ 2021-08-24 17:41 ` martin rudalics
2021-08-24 20:02 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2021-08-24 17:41 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-24 17:41 ` martin rudalics
@ 2021-08-24 20:02 ` Drew Adams
2021-08-25 7:48 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-24 20:02 UTC (permalink / raw)
To: martin rudalics, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> > (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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-24 20:02 ` Drew Adams
@ 2021-08-25 7:48 ` martin rudalics
2021-08-25 15:27 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2021-08-25 7:48 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-25 7:48 ` martin rudalics
@ 2021-08-25 15:27 ` Drew Adams
2021-08-25 19:41 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-25 15:27 UTC (permalink / raw)
To: martin rudalics, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> > 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?
"the parameters of `special-display-regexps'".
I want the *Backtrace* frame to look and act like
frames for other buffers whose names also match
that regexp.
> > 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.
Meaning what - what "certain knowledge"? I guess
you're suggesting that I lack it, so it would be
good to know what it is.
> >> 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),
I define the frame parameters separately, with a
user option, `1on1-special-display-frame-alist'
(which others besides myself use). The setting of
just `special-display-regexps' is in my init file,
for myself alone.
Put differently, I separate the appearance of
special-display frames from a criterion (in this
case buffer-name-matching-regexp) for which buffers
get special-display frames.
That's also the purpose, presumably, of option
`special-display-frame-alist' (which option
`1on1-special-display-frame-alist' augments).
> >> > 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.
Sorry, I don't know what you're referring to.
Could you be specific?
> >> 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.
See above.
Is there some specific caveat about using this hook,
which is not in the Elisp manual? Nothing particular
is said in the manual about the hook.
What special Elisp knowledge is required? Why the
vague formulation (repeated) of "a certain knowledge"?
It's not clear to me what you're suggesting.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-25 15:27 ` Drew Adams
@ 2021-08-25 19:41 ` martin rudalics
2021-08-25 20:23 ` Drew Adams
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2021-08-25 19:41 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
>> What would you have to "duplicate" here?
>
> "the parameters of `special-display-regexps'".
>
> I want the *Backtrace* frame to look and act like
> frames for other buffers whose names also match
> that regexp.
Why can't you add the `no-other-frame' parameter to that common list for
the *Backtrace* buffer alone?
>> Using `after-make-frame-functions' requires a
>> certain knowledge of Elisp.
>
> Meaning what - what "certain knowledge"? I guess
> you're suggesting that I lack it, so it would be
> good to know what it is.
I lack it and that's why I neither use nor recommend using
`after-make-frame-functions'.
> I define the frame parameters separately, with a
> user option, `1on1-special-display-frame-alist'
> (which others besides myself use). The setting of
> just `special-display-regexps' is in my init file,
> for myself alone.
>
> Put differently, I separate the appearance of
> special-display frames from a criterion (in this
> case buffer-name-matching-regexp) for which buffers
> get special-display frames.
>
> That's also the purpose, presumably, of option
> `special-display-frame-alist' (which option
> `1on1-special-display-frame-alist' augments).
And you cannot augment that alist by additional elements for specific
buffers?
>> > 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.
>
> Sorry, I don't know what you're referring to.
> Could you be specific?
These options have been provided to control the display of buffers where
the user does not "control how or when the frame gets created".
>> Because using `after-make-frame-functions' requires
>> a certain knowledge of Elisp.
>
> See above.
>
> Is there some specific caveat about using this hook,
> which is not in the Elisp manual? Nothing particular
> is said in the manual about the hook.
>
> What special Elisp knowledge is required? Why the
> vague formulation (repeated) of "a certain knowledge"?
> It's not clear to me what you're suggesting.
If you understand how frame names, explicit names and titles are set up,
you know much more than I do. But in that case you should not have made
the wrong assumption about the name of the *Backtrace* frame at the time
`after-make-frame-functions' is run. So what I am suggesting is that
since we both don't know all too much about this subject, it might be
better for us to avoid using `after-make-frame-functions' in code we
write.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-25 19:41 ` martin rudalics
@ 2021-08-25 20:23 ` Drew Adams
2021-08-26 7:53 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2021-08-25 20:23 UTC (permalink / raw)
To: martin rudalics, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
> >> What would you have to "duplicate" here?
> > "the parameters of `special-display-regexps'".
> >
> > I want the *Backtrace* frame to look and act like
> > frames for other buffers whose names also match
> > that regexp.
>
> Why can't you add the `no-other-frame' parameter to that common list for
> the *Backtrace* buffer alone?
Dunno what you mean. (But it sounds like duplicating
the common list, and adding something to the copy.)
> >> Using `after-make-frame-functions' requires a
> >> certain knowledge of Elisp.
> >
> > Meaning what - what "certain knowledge"? I guess
> > you're suggesting that I lack it, so it would be
> > good to know what it is.
>
> I lack it and that's why I neither use nor recommend using
> `after-make-frame-functions'.
Well, if you lack it then certainly I do too.
Why doesn't its doc give users a heads-up in this
(unspecified) regard, if it requires special
knowledge or handling?
> > I define the frame parameters separately, with a
> > user option, `1on1-special-display-frame-alist'
> > (which others besides myself use). The setting of
> > just `special-display-regexps' is in my init file,
> > for myself alone.
> >
> > Put differently, I separate the appearance of
> > special-display frames from a criterion (in this
> > case buffer-name-matching-regexp) for which buffers
> > get special-display frames.
> >
> > That's also the purpose, presumably, of option
> > `special-display-frame-alist' (which option
> > `1on1-special-display-frame-alist' augments).
>
> And you cannot augment that alist by additional elements for specific
> buffers?
Dunno what you mean. It's just like
`special-display-frame-alist' - an alist of frame
parameters. It applies to all special-display
buffers.
> >> > 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.
> >
> > Sorry, I don't know what you're referring to.
> > Could you be specific?
>
> These options have been provided to control the display of buffers where
> the user does not "control how or when the frame gets created".
`display-buffer-alist' terrifies me. ;-)
> >> Because using `after-make-frame-functions' requires
> >> a certain knowledge of Elisp.
> >
> > See above.
> >
> > Is there some specific caveat about using this hook,
> > which is not in the Elisp manual? Nothing particular
> > is said in the manual about the hook.
> >
> > What special Elisp knowledge is required? Why the
> > vague formulation (repeated) of "a certain knowledge"?
> > It's not clear to me what you're suggesting.
>
> If you understand how frame names, explicit names and titles are set up,
> you know much more than I do.
I certainly don't know more than you. And I don't
think I've given the impression that I think I do.
Certainly haven't meant that.
> But in that case you should not have made
> the wrong assumption about the name of the *Backtrace*
> frame at the time `after-make-frame-functions' is run.
Yes, that was my bad. Even without knowing that
that was the problem I should have thought to try
code such as what you suggested.
> So what I am suggesting is that since we both
> don't know all too much about this subject, it
> might be better for us to avoid using
> `after-make-frame-functions' in code we write.
Maybe so, and thanks for the warning. So far, I
have something that seems to work, and I'm not
sure what an alternative way to handle it would
be. I don't mean to take your time in trying to
do that, but I do appreciate your advice.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
2021-08-25 20:23 ` Drew Adams
@ 2021-08-26 7:53 ` martin rudalics
0 siblings, 0 replies; 17+ messages in thread
From: martin rudalics @ 2021-08-26 7:53 UTC (permalink / raw)
To: Drew Adams, Lars Ingebrigtsen; +Cc: 13336@debbugs.gnu.org
>> Why can't you add the `no-other-frame' parameter to that common list for
>> the *Backtrace* buffer alone?
>
> Dunno what you mean. (But it sounds like duplicating
> the common list, and adding something to the copy.)
Maintain a 'basic-alist' of frame parameters and for the *Backtrace*
buffer use
(cons (cons 'no-other-frame t) basic-alist)
as list of frame parameters.
> Why doesn't its doc give users a heads-up in this
> (unspecified) regard, if it requires special
> knowledge or handling?
I don't know but there is one thing I know for sure: Setting up a frame
and using `after-make-frame-functions' to add or a change a parameter is
madness. Creating a frame mostly means to process frame parameters in a
carefully laid out fashion. If, at the end of that, a user decides that
some additional parameter should be processed, this may confuse the hell
out of that process. Never do that - specify all parameters you need at
the time you ask Emacs to create the frame.
>> And you cannot augment that alist by additional elements for specific
>> buffers?
>
> Dunno what you mean. It's just like
> `special-display-frame-alist' - an alist of frame
> parameters. It applies to all special-display
> buffers.
See above.
> `display-buffer-alist' terrifies me. ;-)
It's just as terrific as `special-display-regexps'.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-08-26 7:53 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-02 18:13 bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked Drew Adams
2017-01-30 6:33 ` npostavs
2017-01-30 14:32 ` Drew Adams
2017-01-31 3:22 ` npostavs
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
2021-08-23 15:20 ` bug#13336: [External] : " Drew Adams
2021-08-23 16:06 ` martin rudalics
2021-08-23 17:41 ` Drew Adams
2021-08-24 9:41 ` martin rudalics
2021-08-24 15:49 ` Drew Adams
2021-08-24 17:41 ` martin rudalics
2021-08-24 20:02 ` Drew Adams
2021-08-25 7:48 ` martin rudalics
2021-08-25 15:27 ` Drew Adams
2021-08-25 19:41 ` martin rudalics
2021-08-25 20:23 ` Drew Adams
2021-08-26 7:53 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).