* Uhm... weird frame behaviour
@ 2011-09-10 19:14 Lars Magne Ingebrigtsen
2011-09-10 22:13 ` Lars Magne Ingebrigtsen
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 19:14 UTC (permalink / raw)
To: emacs-devel
This is odd. The first time it happened, I thought I had hit the wrong
keys. And then it happened again.
Ok, this is one of these nebulous bug reports, which is why I didn't
report it as a bug.
What happens is this:
I usually have two frames open when using Gnus and fixing bugs. One
frame for reading mail and one for fixing bugs. :-)
Two times now, when sending the email with `C-c C-c', that frame has
disappeared.
I'm not able to reproduce it reliably at all. Out of the 20 mails I've
sent within the last hour, only two have resulted in the frame
disappearing.
Has anybody else seen anything like this?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-10 19:14 Uhm... weird frame behaviour Lars Magne Ingebrigtsen
@ 2011-09-10 22:13 ` Lars Magne Ingebrigtsen
2011-09-11 9:34 ` martin rudalics
2011-09-10 23:40 ` Rasmus
2011-09-11 0:05 ` Óscar Fuentes
2 siblings, 1 reply; 40+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 22:13 UTC (permalink / raw)
To: emacs-devel
Now I have a reproducible case. If I `q' in the group buffer in Gnus,
the frame is killed.
Can this be explained by any of the recent window code shenanigans?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-10 22:13 ` Lars Magne Ingebrigtsen
@ 2011-09-11 9:34 ` martin rudalics
2011-09-11 15:27 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: martin rudalics @ 2011-09-11 9:34 UTC (permalink / raw)
To: emacs-devel
> Now I have a reproducible case. If I `q' in the group buffer in Gnus,
> the frame is killed.
Which function does `q' run?
> Can this be explained by any of the recent window code shenanigans?
It's probably because the frame in question didn't show another buffer
before. Which buffer did you expect it to show after typing `q'? In
any case you should be able to turn this behavior off by customizing
`window-auto-delete' to nil or 'window.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-11 9:34 ` martin rudalics
@ 2011-09-11 15:27 ` Lars Magne Ingebrigtsen
2011-09-11 15:44 ` Lars Magne Ingebrigtsen
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-11 15:27 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
martin rudalics <rudalics@gmx.at> writes:
> Which function does `q' run?
`gnus-group-quit'.
>> Can this be explained by any of the recent window code shenanigans?
>
> It's probably because the frame in question didn't show another buffer
> before. Which buffer did you expect it to show after typing `q'?
Any random buffer. Killing a buffer has never deleted a frame before.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-11 15:27 ` Lars Magne Ingebrigtsen
@ 2011-09-11 15:44 ` Lars Magne Ingebrigtsen
2011-09-12 9:04 ` martin rudalics
2011-09-12 9:04 ` martin rudalics
2011-09-13 18:28 ` martin rudalics
2 siblings, 1 reply; 40+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-11 15:44 UTC (permalink / raw)
To: emacs-devel
I also tried
(setq delete-frame-functions '(debug))
to see whether I could see what's deleting mah frames, but it's
apparently not being called?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-11 15:27 ` Lars Magne Ingebrigtsen
2011-09-11 15:44 ` Lars Magne Ingebrigtsen
@ 2011-09-12 9:04 ` martin rudalics
2011-09-12 12:22 ` Óscar Fuentes
` (2 more replies)
2011-09-13 18:28 ` martin rudalics
2 siblings, 3 replies; 40+ messages in thread
From: martin rudalics @ 2011-09-12 9:04 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
>> Which function does `q' run?
>
> `gnus-group-quit'.
Which ends up calling `kill-buffer'?
>>> Can this be explained by any of the recent window code shenanigans?
>> It's probably because the frame in question didn't show another buffer
>> before. Which buffer did you expect it to show after typing `q'?
>
> Any random buffer.
So you wanted to show a random buffer as placeholder. A buffer you
didn't intend to view or edit.
> Killing a buffer has never deleted a frame before.
See the thread on bug#9419 for an explanation and how to
disable the behavior.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-12 9:04 ` martin rudalics
@ 2011-09-12 12:22 ` Óscar Fuentes
2011-09-12 12:47 ` martin rudalics
2011-09-12 12:31 ` Óscar Fuentes
2011-09-12 13:32 ` Andy Moreton
2 siblings, 1 reply; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-12 12:22 UTC (permalink / raw)
To: emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>> Killing a buffer has never deleted a frame before.
>
> See the thread on bug#9419 for an explanation and how to
> disable the behavior.
That's a long thread and I just only skimmed over it, but the only frame
of my Emacs session is deleted from time to time forcing me to create a
new one with emacsclient (I'm using the daemon.) That's a bug.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 12:22 ` Óscar Fuentes
@ 2011-09-12 12:47 ` martin rudalics
2011-09-12 13:32 ` Óscar Fuentes
0 siblings, 1 reply; 40+ messages in thread
From: martin rudalics @ 2011-09-12 12:47 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
> ... but the only frame
> of my Emacs session is deleted from time to time forcing me to create a
> new one with emacsclient (I'm using the daemon.) That's a bug.
This would constitute a bug by itself. Does it also happen when you do
`delete-windows-on' for the only visible buffer? What does
`other-visible-frames-p' return when you're on "the only frame of your
Emacs session"?
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 12:47 ` martin rudalics
@ 2011-09-12 13:32 ` Óscar Fuentes
2011-09-12 14:55 ` martin rudalics
0 siblings, 1 reply; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-12 13:32 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>> ... but the only frame
>> of my Emacs session is deleted from time to time forcing me to create a
>> new one with emacsclient (I'm using the daemon.) That's a bug.
>
> This would constitute a bug by itself. Does it also happen when you do
> `delete-windows-on' for the only visible buffer?
Yes, the frame is deleted.
Setting window-auto-delete to nil or 'window does not help.
Just tried again with emacs -Q --daemon : same problem.
> What does `other-visible-frames-p' return when you're on "the only
> frame of your Emacs session"?
t
On a non-daemonized emacs session, `delete-windows-on' does not delete
the frame and `other-visible-frames-p' returns nil.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 13:32 ` Óscar Fuentes
@ 2011-09-12 14:55 ` martin rudalics
2011-09-12 15:34 ` Óscar Fuentes
0 siblings, 1 reply; 40+ messages in thread
From: martin rudalics @ 2011-09-12 14:55 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
>> This would constitute a bug by itself. Does it also happen when you do
>> `delete-windows-on' for the only visible buffer?
>
> Yes, the frame is deleted.
>
> Setting window-auto-delete to nil or 'window does not help.
>
> Just tried again with emacs -Q --daemon : same problem.
>
>> What does `other-visible-frames-p' return when you're on "the only
>> frame of your Emacs session"?
>
> t
I don't understand that. Is the daemon frame iconified? If nobody can
tell, could you step through other_visible_frames to find out why there
are two visible frames?
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 14:55 ` martin rudalics
@ 2011-09-12 15:34 ` Óscar Fuentes
2011-09-12 16:01 ` Eli Zaretskii
0 siblings, 1 reply; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-12 15:34 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>>> This would constitute a bug by itself. Does it also happen when you do
>>> `delete-windows-on' for the only visible buffer?
>>
>> Yes, the frame is deleted.
>>
>> Setting window-auto-delete to nil or 'window does not help.
>>
>> Just tried again with emacs -Q --daemon : same problem.
>>
>>> What does `other-visible-frames-p' return when you're on "the only
>>> frame of your Emacs session"?
>>
>> t
>
> I don't understand that. Is the daemon frame iconified?
AFAIK the daemon has no frame. The user must create one. I do that with
`emacsclient -c -n'.
> If nobody can
> tell, could you step through other_visible_frames to find out why there
> are two visible frames?
Indeed, the function is counting two visible frames:
Breakpoint 1, other_visible_frames (f=0xf43590) at /home/oscar/dev/emacs/emacs/src/frame.c:1120
1120 {
(gdb) n
1123 if (f == SELECTED_FRAME ())
(gdb) print f
$1 = (FRAME_PTR) 0xf43590
(gdb) n
1128 for (frames = Vframe_list;
(gdb)
1134 this = XCAR (frames);
(gdb)
1139 if (FRAME_WINDOW_P (XFRAME (this)))
(gdb)
1141 x_sync (XFRAME (this));
(gdb)
1142 FRAME_SAMPLE_VISIBILITY (XFRAME (this));
(gdb)
1146 if (FRAME_VISIBLE_P (XFRAME (this))
(gdb)
1151 count++;
(gdb)
1130 frames = XCDR (frames))
(gdb)
1128 for (frames = Vframe_list;
(gdb)
1134 this = XCAR (frames);
(gdb)
1139 if (FRAME_WINDOW_P (XFRAME (this)))
(gdb)
1146 if (FRAME_VISIBLE_P (XFRAME (this))
(gdb)
1151 count++;
(gdb)
1130 frames = XCDR (frames))
(gdb)
1128 for (frames = Vframe_list;
(gdb)
1156 }
(gdb)
Fother_visible_frames_p (frame=<value optimized out>)
at /home/oscar/dev/emacs/emacs/src/frame.c:1167
1167 }
(gdb) c
Continuing.
Evaluating (frame-list) gives
(#<frame emacs@qcore 0xf43590> #<frame F1 0xb6e7d0>)
I have no idea what frame F1 is. The only displayed frame is
`emacs@qcore', which is what `emacsclient -c -n' creates.
Just to reiterate, this is with `emacs -Q --daemon'.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-12 15:34 ` Óscar Fuentes
@ 2011-09-12 16:01 ` Eli Zaretskii
2011-09-12 16:20 ` Eli Zaretskii
0 siblings, 1 reply; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 16:01 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: rudalics, emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 12 Sep 2011 17:34:45 +0200
> Cc: emacs-devel@gnu.org
>
> Evaluating (frame-list) gives
>
> (#<frame emacs@qcore 0xf43590> #<frame F1 0xb6e7d0>)
>
> I have no idea what frame F1 is. The only displayed frame is
> `emacs@qcore', which is what `emacsclient -c -n' creates.
Frames whose names are F1, F2, etc. are terminal frames. Is it
possible that the demonic Emacs doesn't delete the initial terminal
frame, like an otherwise "normal" interactive session would?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 16:01 ` Eli Zaretskii
@ 2011-09-12 16:20 ` Eli Zaretskii
2011-09-12 17:16 ` Óscar Fuentes
2011-09-12 18:26 ` martin rudalics
0 siblings, 2 replies; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 16:20 UTC (permalink / raw)
To: rudalics, emacs-devel
> Date: Mon, 12 Sep 2011 19:01:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
>
> > (#<frame emacs@qcore 0xf43590> #<frame F1 0xb6e7d0>)
> >
> > I have no idea what frame F1 is. The only displayed frame is
> > `emacs@qcore', which is what `emacsclient -c -n' creates.
>
> Frames whose names are F1, F2, etc. are terminal frames. Is it
> possible that the demonic Emacs doesn't delete the initial terminal
> frame, like an otherwise "normal" interactive session would?
Answering my own question: yes, that's what happens.
So Martin, I think other_visible_frames should be augmented for the
fact that when IS_DAEMON is non-zero, there's one frame that is always
there and does not constitute "other frames".
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 16:20 ` Eli Zaretskii
@ 2011-09-12 17:16 ` Óscar Fuentes
2011-09-12 17:33 ` Eli Zaretskii
2011-09-12 17:37 ` Eli Zaretskii
2011-09-12 18:26 ` martin rudalics
1 sibling, 2 replies; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-12 17:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> > (#<frame emacs@qcore 0xf43590> #<frame F1 0xb6e7d0>)
>> >
>> > I have no idea what frame F1 is. The only displayed frame is
>> > `emacs@qcore', which is what `emacsclient -c -n' creates.
>>
>> Frames whose names are F1, F2, etc. are terminal frames. Is it
>> possible that the demonic Emacs doesn't delete the initial terminal
>> frame, like an otherwise "normal" interactive session would?
>
> Answering my own question: yes, that's what happens.
>
> So Martin, I think other_visible_frames should be augmented for the
> fact that when IS_DAEMON is non-zero, there's one frame that is always
> there and does not constitute "other frames".
It seems more correct to fix the FRAME_VISIBLE_P test for that F1 frame.
OTOH:
emacs -Q
M-x server-start
(from a terminal): emacsclient -c -nw
(on the emacs' X frame): M-x delete-windows-on (select the currently
displayed buffer)
The graphical frame goes away. This is not correct, IMO.
Another example: running emacs as a server as above, connect from a
remote X server and create an emacs frame there. On one of the two
machines, M-x delete-windows-on (choose the currently displayed buffer.)
The frame on the other machine is deleted.
So this feature about smartly deleting frames is broken for some use
cases.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 17:16 ` Óscar Fuentes
@ 2011-09-12 17:33 ` Eli Zaretskii
2011-09-12 17:37 ` Eli Zaretskii
1 sibling, 0 replies; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 17:33 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: rudalics, emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> Date: Mon, 12 Sep 2011 19:16:29 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
> > So Martin, I think other_visible_frames should be augmented for the
> > fact that when IS_DAEMON is non-zero, there's one frame that is always
> > there and does not constitute "other frames".
>
> It seems more correct to fix the FRAME_VISIBLE_P test for that F1 frame.
I'm not sure. In fact, I don't understand why that function even
tests frame visibility, or maybe I don't understand its contract.
> So this feature about smartly deleting frames is broken for some use
> cases.
I'm sure Martin will fix whatever needs fixing. But bugs are not
necessarily a valid argument against intended behavior.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 17:16 ` Óscar Fuentes
2011-09-12 17:33 ` Eli Zaretskii
@ 2011-09-12 17:37 ` Eli Zaretskii
1 sibling, 0 replies; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 17:37 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: rudalics, emacs-devel
> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: rudalics@gmx.at, emacs-devel@gnu.org
> Date: Mon, 12 Sep 2011 19:16:29 +0200
>
> emacs -Q
>
> M-x server-start
>
> (from a terminal): emacsclient -c -nw
>
> (on the emacs' X frame): M-x delete-windows-on (select the currently
> displayed buffer)
>
> The graphical frame goes away.
I guess other_visible_frames should also consider which terminal those
other frames are visible on. If the frame under consideration is the
only one on its terminal, then it should not be deleted.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 16:20 ` Eli Zaretskii
2011-09-12 17:16 ` Óscar Fuentes
@ 2011-09-12 18:26 ` martin rudalics
2011-09-12 19:12 ` Eli Zaretskii
2011-09-12 19:17 ` Chong Yidong
1 sibling, 2 replies; 40+ messages in thread
From: martin rudalics @ 2011-09-12 18:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> Frames whose names are F1, F2, etc. are terminal frames. Is it
>> possible that the demonic Emacs doesn't delete the initial terminal
>> frame, like an otherwise "normal" interactive session would?
>
> Answering my own question: yes, that's what happens.
Funny. I thought that
When Emacs is
invoked with the `--daemon' option, it does not create any initial
frames, so `initial-window-system' is `nil'.
Does it create a frame afterwards?
> So Martin, I think other_visible_frames should be augmented for the
> fact that when IS_DAEMON is non-zero, there's one frame that is always
> there and does not constitute "other frames".
This would break `delete-frame' which apparently _should_ delete a frame
even if it's the last one in that case. (I think so because nobody ever
complained about this fact.) Is there a way to get IS_DAEMON in Elisp,
`initial-window-system' is deprecated AFAICT.
BTW, the bug should be already present in Emacs 23 when you quit a help
frame or a dedicated frame and that frame is the last visible frame.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-12 18:26 ` martin rudalics
@ 2011-09-12 19:12 ` Eli Zaretskii
2011-09-13 11:59 ` martin rudalics
2011-09-12 19:17 ` Chong Yidong
1 sibling, 1 reply; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 19:12 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel
> Date: Mon, 12 Sep 2011 20:26:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
>
> >> Frames whose names are F1, F2, etc. are terminal frames. Is it
> >> possible that the demonic Emacs doesn't delete the initial terminal
> >> frame, like an otherwise "normal" interactive session would?
> >
> > Answering my own question: yes, that's what happens.
>
> Funny. I thought that
>
> When Emacs is
> invoked with the `--daemon' option, it does not create any initial
> frames, so `initial-window-system' is `nil'.
This describes a different "initial frame", the one that's visible to
the user. See below.
> Does it create a frame afterwards?
No. I was talking about the frame that is created and dumped by
temacs. It is never actually displayed, just used through the initial
part of the startup, and then deleted (except in a daemonic Emacs),
when the "real" initial frame is created.
> > So Martin, I think other_visible_frames should be augmented for the
> > fact that when IS_DAEMON is non-zero, there's one frame that is always
> > there and does not constitute "other frames".
>
> This would break `delete-frame' which apparently _should_ delete a frame
> even if it's the last one in that case.
??? That special frame cannot possibly be deleted anyway, because it
is never displayed. Are we talking about the same thing?
> Is there a way to get IS_DAEMON in Elisp,
Yes, it's called `daemonp'.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 19:12 ` Eli Zaretskii
@ 2011-09-13 11:59 ` martin rudalics
0 siblings, 0 replies; 40+ messages in thread
From: martin rudalics @ 2011-09-13 11:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
>> This would break `delete-frame' which apparently _should_ delete a frame
>> even if it's the last one in that case.
>
> ??? That special frame cannot possibly be deleted anyway, because it
> is never displayed.
Are you sure? Even if there's another visible frame?
> Are we talking about the same thing?
By "that case" I meant the last visible frame. `other-visible-frames-p`
calls other_visible_frames which is the routine `delete-frame' uses to
decide whether a frame can be deleted with FORCE nil. So the criterion
I use is the same criterion used by `delete-frame'.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 18:26 ` martin rudalics
2011-09-12 19:12 ` Eli Zaretskii
@ 2011-09-12 19:17 ` Chong Yidong
2011-09-13 12:00 ` martin rudalics
1 sibling, 1 reply; 40+ messages in thread
From: Chong Yidong @ 2011-09-12 19:17 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel
martin rudalics <rudalics@gmx.at> writes:
> Is there a way to get IS_DAEMON in Elisp, `initial-window-system' is
> deprecated AFAICT.
The function `daemonp' is for this. But I don't think daemon mode has
much to do with this. The issue is more fundamental:
Firstly, the function window-deletable-p should only look at frames on
the current terminal. Emacs should never automatically delete the last
frame on a terminal; that is obnoxious. So other-visible-frames-p needs
to be changed to handle this. (Not sure why that function is in C, btw;
it could be written in Lisp.)
Secondly, the current code is too aggressive in deciding that a frame
can be deleted. Consider the following sequence:
C-h k RET
C-x o => switch to the *Help* window
C-x 5 2 => pop to a new frame displaying *Help*
q => the frame is deleted
I don't think this is quite right. The new frame was not created as a
"temporary frame" for displaying the *Help* window, but by the user's
explicit `C-x 5 2' command. It just so happened that a special-mode
buffer was current at the time. In this situation, quit-window should
not delete the frame.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 19:17 ` Chong Yidong
@ 2011-09-13 12:00 ` martin rudalics
2011-09-13 12:45 ` Óscar Fuentes
2011-09-13 15:41 ` Chong Yidong
0 siblings, 2 replies; 40+ messages in thread
From: martin rudalics @ 2011-09-13 12:00 UTC (permalink / raw)
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
> Firstly, the function window-deletable-p should only look at frames on
> the current terminal.
How would it do this? Via `next-frame'? Can someone check whether this
DTRT for the daemon frame?
> Emacs should never automatically delete the last
> frame on a terminal; that is obnoxious. So other-visible-frames-p needs
> to be changed to handle this. (Not sure why that function is in C, btw;
> it could be written in Lisp.)
Without doing FRAME_SAMPLE_VISIBILITY? I have no idea how to do that so
I'd be grateful if someone wrote such a function. I'm somewhat lost
with daemons and terminals.
> Secondly, the current code is too aggressive in deciding that a frame
> can be deleted. Consider the following sequence:
>
> C-h k RET
> C-x o => switch to the *Help* window
> C-x 5 2 => pop to a new frame displaying *Help*
> q => the frame is deleted
>
> I don't think this is quite right. The new frame was not created as a
> "temporary frame" for displaying the *Help* window, but by the user's
> explicit `C-x 5 2' command. It just so happened that a special-mode
> buffer was current at the time. In this situation, quit-window should
> not delete the frame.
Then I'll revert to the previous behavior which kills the frame even if it
has some buffer it could show instead.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-13 12:00 ` martin rudalics
@ 2011-09-13 12:45 ` Óscar Fuentes
2011-09-13 18:28 ` martin rudalics
2011-09-13 15:41 ` Chong Yidong
1 sibling, 1 reply; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-13 12:45 UTC (permalink / raw)
To: martin rudalics; +Cc: Chong Yidong, Eli Zaretskii, emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>> Firstly, the function window-deletable-p should only look at frames on
>> the current terminal.
>
> How would it do this? Via `next-frame'? Can someone check whether this
> DTRT for the daemon frame?
next-frame skips the daemon frame when invoked with the graphical frame
as its argument, and vice-versa.
[snip]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-13 12:00 ` martin rudalics
2011-09-13 12:45 ` Óscar Fuentes
@ 2011-09-13 15:41 ` Chong Yidong
2011-09-13 18:27 ` martin rudalics
1 sibling, 1 reply; 40+ messages in thread
From: Chong Yidong @ 2011-09-13 15:41 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>> Emacs should never automatically delete the last frame on a terminal;
>> that is obnoxious. So other-visible-frames-p needs to be changed to
>> handle this. (Not sure why that function is in C, btw; it could be
>> written in Lisp.)
>
> Without doing FRAME_SAMPLE_VISIBILITY? I have no idea how to do that so
> I'd be grateful if someone wrote such a function. I'm somewhat lost
> with daemons and terminals.
I've fixed this directly in window-deletable-p.
>> Secondly, the current code is too aggressive in deciding that a frame
>> can be deleted. Consider the following sequence:
>>
>> C-h k RET
>> C-x o => switch to the *Help* window
>> C-x 5 2 => pop to a new frame displaying *Help*
>> q => the frame is deleted
>>
>> I don't think this is quite right. The new frame was not created as a
>> "temporary frame" for displaying the *Help* window, but by the user's
>> explicit `C-x 5 2' command. It just so happened that a special-mode
>> buffer was current at the time. In this situation, quit-window should
>> not delete the frame.
>
> Then I'll revert to the previous behavior which kills the frame even if it
> has some buffer it could show instead.
Note sure what you mean. Wouldn't that make the frame deletion even
more aggressive?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-13 15:41 ` Chong Yidong
@ 2011-09-13 18:27 ` martin rudalics
2011-09-13 19:09 ` Chong Yidong
0 siblings, 1 reply; 40+ messages in thread
From: martin rudalics @ 2011-09-13 18:27 UTC (permalink / raw)
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
> I've fixed this directly in window-deletable-p.
Thanks. Apparently
(not (eq (next-frame nil 0) (selected-frame))))
which is in `bury-buffer' should do the same. Do you see any
differences?
>> Then I'll revert to the previous behavior which kills the frame even if it
>> has some buffer it could show instead.
>
> Note sure what you mean. Wouldn't that make the frame deletion even
> more aggressive?
Hopefully not. The drawback now is that with `pop-up-frames' non-nil
doing
C-h k RET
M-x prev-buffer
M-x next-buffer
q
will delete the frame although it could show the buffer shown by
`prev-buffer' instead.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 9:04 ` martin rudalics
2011-09-12 12:22 ` Óscar Fuentes
@ 2011-09-12 12:31 ` Óscar Fuentes
2011-09-12 12:47 ` martin rudalics
2011-09-12 13:32 ` Andy Moreton
2 siblings, 1 reply; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-12 12:31 UTC (permalink / raw)
To: emacs-devel
martin rudalics <rudalics@gmx.at> writes:
> See the thread on bug#9419 for an explanation and how to
> disable the behavior.
The thread mentions frame-auto-delete, but it is not a defined variable
nor it is mentioned on the source files on lisp/.
So how do I disable the deleting of frames?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 9:04 ` martin rudalics
2011-09-12 12:22 ` Óscar Fuentes
2011-09-12 12:31 ` Óscar Fuentes
@ 2011-09-12 13:32 ` Andy Moreton
2011-09-12 13:39 ` Eli Zaretskii
2 siblings, 1 reply; 40+ messages in thread
From: Andy Moreton @ 2011-09-12 13:32 UTC (permalink / raw)
To: emacs-devel
On Mon 12 Sep 2011, martin rudalics wrote:
>>> Which function does `q' run?
>>
>> `gnus-group-quit'.
>
> Which ends up calling `kill-buffer'?
>
>>>> Can this be explained by any of the recent window code shenanigans?
>>> It's probably because the frame in question didn't show another buffer
>>> before. Which buffer did you expect it to show after typing `q'?
>>
>> Any random buffer.
>
> So you wanted to show a random buffer as placeholder. A buffer you
> didn't intend to view or edit.
I think Lars would like the previous behaviour, where some buffer is chosen
for display (which buffer is not important).
I'd like this fixed too, as frames being randomly deleted is
disconcerting to say the least.
>> Killing a buffer has never deleted a frame before.
>
> See the thread on bug#9419 for an explanation and how to
> disable the behavior.
Emacs previously did not delete frames is this way, so it is a
regression and thus a bug to be fixed.
If configuration is required to fix this behaviour, then the default
setting is wrong and needs to be changed.
AndyM
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Uhm... weird frame behaviour
2011-09-12 13:32 ` Andy Moreton
@ 2011-09-12 13:39 ` Eli Zaretskii
2011-09-12 16:52 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 40+ messages in thread
From: Eli Zaretskii @ 2011-09-12 13:39 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 12 Sep 2011 14:32:57 +0100
>
> I think Lars would like the previous behaviour, where some buffer is chosen
> for display (which buffer is not important).
>
> I'd like this fixed too, as frames being randomly deleted is
> disconcerting to say the least.
>
> >> Killing a buffer has never deleted a frame before.
> >
> > See the thread on bug#9419 for an explanation and how to
> > disable the behavior.
>
> Emacs previously did not delete frames is this way, so it is a
> regression and thus a bug to be fixed.
>
> If configuration is required to fix this behaviour, then the default
> setting is wrong and needs to be changed.
There's a certain conflict here between two groups of users: those who
set pop-up-frames non-nil, and those who don't. The former want the
current default, while most of the latter I suspect would want the
previous behavior, maybe out of habit, maybe for some other reason.
We need to find a good way of giving each group the default they want.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-12 13:39 ` Eli Zaretskii
@ 2011-09-12 16:52 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 40+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-12 16:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andy Moreton, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> There's a certain conflict here between two groups of users: those who
> set pop-up-frames non-nil, and those who don't. The former want the
> current default, while most of the latter I suspect would want the
> previous behavior, maybe out of habit, maybe for some other reason.
I think that's a good analysis of the situation. I have `pop-up-frames'
nil, and I just create two frames at startup. I never add or delete any
frames. Having the second frame disappear, seemingly at random, puts a
serious crimp in my work flow.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-11 15:27 ` Lars Magne Ingebrigtsen
2011-09-11 15:44 ` Lars Magne Ingebrigtsen
2011-09-12 9:04 ` martin rudalics
@ 2011-09-13 18:28 ` martin rudalics
2011-09-13 20:26 ` Lars Magne Ingebrigtsen
2 siblings, 1 reply; 40+ messages in thread
From: martin rudalics @ 2011-09-13 18:28 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: emacs-devel
> Killing a buffer has never deleted a frame before.
It should behave now as before. Please check.
martin
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-10 19:14 Uhm... weird frame behaviour Lars Magne Ingebrigtsen
2011-09-10 22:13 ` Lars Magne Ingebrigtsen
@ 2011-09-10 23:40 ` Rasmus
2011-09-10 23:42 ` Lars Magne Ingebrigtsen
2011-09-10 23:46 ` Rasmus
2011-09-11 0:05 ` Óscar Fuentes
2 siblings, 2 replies; 40+ messages in thread
From: Rasmus @ 2011-09-10 23:40 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Has anybody else seen anything like this?
Yes, I have seen this as well. In particular when clicking 'q' in Gnus
summary buffer. I have not seen it since I updated to bzr 105697,
though. It may be a coincidence.
–Rasmus
--
Sent from my Emacs
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Uhm... weird frame behaviour
2011-09-10 19:14 Uhm... weird frame behaviour Lars Magne Ingebrigtsen
2011-09-10 22:13 ` Lars Magne Ingebrigtsen
2011-09-10 23:40 ` Rasmus
@ 2011-09-11 0:05 ` Óscar Fuentes
2 siblings, 0 replies; 40+ messages in thread
From: Óscar Fuentes @ 2011-09-11 0:05 UTC (permalink / raw)
To: emacs-devel
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Has anybody else seen anything like this?
Yes, just happened to me after pressing `q' on a Compile buffer. As
Rasmus says, the frame is killed but the daemon keeps running. I'm on
trunk r105703.
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2011-09-14 1:34 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-10 19:14 Uhm... weird frame behaviour Lars Magne Ingebrigtsen
2011-09-10 22:13 ` Lars Magne Ingebrigtsen
2011-09-11 9:34 ` martin rudalics
2011-09-11 15:27 ` Lars Magne Ingebrigtsen
2011-09-11 15:44 ` Lars Magne Ingebrigtsen
2011-09-12 9:04 ` martin rudalics
2011-09-12 9:04 ` martin rudalics
2011-09-12 12:22 ` Óscar Fuentes
2011-09-12 12:47 ` martin rudalics
2011-09-12 13:32 ` Óscar Fuentes
2011-09-12 14:55 ` martin rudalics
2011-09-12 15:34 ` Óscar Fuentes
2011-09-12 16:01 ` Eli Zaretskii
2011-09-12 16:20 ` Eli Zaretskii
2011-09-12 17:16 ` Óscar Fuentes
2011-09-12 17:33 ` Eli Zaretskii
2011-09-12 17:37 ` Eli Zaretskii
2011-09-12 18:26 ` martin rudalics
2011-09-12 19:12 ` Eli Zaretskii
2011-09-13 11:59 ` martin rudalics
2011-09-12 19:17 ` Chong Yidong
2011-09-13 12:00 ` martin rudalics
2011-09-13 12:45 ` Óscar Fuentes
2011-09-13 18:28 ` martin rudalics
2011-09-14 1:34 ` Óscar Fuentes
2011-09-13 15:41 ` Chong Yidong
2011-09-13 18:27 ` martin rudalics
2011-09-13 19:09 ` Chong Yidong
2011-09-12 12:31 ` Óscar Fuentes
2011-09-12 12:47 ` martin rudalics
2011-09-12 13:32 ` Andy Moreton
2011-09-12 13:39 ` Eli Zaretskii
2011-09-12 16:52 ` Lars Magne Ingebrigtsen
2011-09-13 18:28 ` martin rudalics
2011-09-13 20:26 ` Lars Magne Ingebrigtsen
2011-09-10 23:40 ` Rasmus
2011-09-10 23:42 ` Lars Magne Ingebrigtsen
2011-09-10 23:46 ` Rasmus
2011-09-10 23:53 ` Lars Magne Ingebrigtsen
2011-09-11 0:05 ` Óscar Fuentes
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).