Uhm... weird frame behaviour

Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

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/

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

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/

Re: Uhm... weird frame behaviour

[Rasmus]

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

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

Rasmus <rasmus@gmx.us> writes:

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

Yes, it seems to have stopped happening now after the last changes Chong
committed a few hours ago.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Uhm... weird frame behaviour

[Rasmus]

Rasmus <rasmus@gmx.us> writes:

>> Has anybody else seen anything like this?
> I have not seen it since I updated to bzr 105697,
> though.  It may be a coincidence.

It just happened after having sent the above mail.

Luckily it only closes the frame and does not destroy the daemon.

–Rasmus

-- 
Sent from my Emacs

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

Rasmus <rasmus@gmx.us> writes:

> It just happened after having sent the above mail.

Yeah, to me, too.  It happens even more now.  Most of the times if I
kill a Gnus buffer, the frame is killed, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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.

Re: Uhm... weird frame behaviour

[martin rudalics]

 > 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

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

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/

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

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/

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Maybe because you're in redisplay.

martin

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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.

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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?

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Try setting `window-auto-delete' to nil or 'window.

martin

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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.

Re: Uhm... weird frame behaviour

[Andy Moreton]

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

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

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/

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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.

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Re: Uhm... weird frame behaviour

[Eli Zaretskii]

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

Re: Uhm... weird frame behaviour

[Chong Yidong]

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.

Re: Uhm... weird frame behaviour

[martin rudalics]

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

Re: Uhm... weird frame behaviour

[martin rudalics]

 > 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

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

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]

Re: Uhm... weird frame behaviour

[Chong Yidong]

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?

Re: Uhm... weird frame behaviour

[martin rudalics]

 > 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

Re: Uhm... weird frame behaviour

[martin rudalics]

 > next-frame skips the daemon frame when invoked with the graphical frame
 > as its argument, and vice-versa.

Thanks.  Chong fixed this problem in the meantime.  Does it work as
intended now?

martin

Re: Uhm... weird frame behaviour

[martin rudalics]

> Killing a buffer has never deleted a frame before.

It should behave now as before.  Please check.

martin

Re: Uhm... weird frame behaviour

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

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

Yes, that is better.  Committed, thanks.

Re: Uhm... weird frame behaviour

[Lars Magne Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> Killing a buffer has never deleted a frame before.
>
> It should behave now as before.  Please check.

I haven't had any frames disappearing suddenly on me the last hour, so I
think this is probably fixed now.  Thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Uhm... weird frame behaviour

[Óscar Fuentes]

martin rudalics <rudalics@gmx.at> writes:

>> next-frame skips the daemon frame when invoked with the graphical frame
>> as its argument, and vice-versa.
>
> Thanks.  Chong fixed this problem in the meantime.  Does it work as
> intended now?

Can't test until the git mirror is updated, but the fix looks
good. Thanks.