GNU bug report logs - #1450
w32_reset_fringes

Previous Next

Full log

Message #35 received at 1450 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 1450 <at> debbugs.gnu.org
Subject: Re: bug#1450: w32_reset_fringes
Date: Sun, 30 Nov 2008 10:19:33 +0100

Thanks for testing this.

> I tried your patch after updating from the current CVS HEAD.  Now
> starting with emacs -q --eval "(setq default-frame-alist
> '((minibuffer)))" and trying to delete the minibuffer frame via the
> window manager does not crash Emacs, but instead results in no deleted
> frame and the error message "Attempt to delete a surrogate minibuffer
> frame" (from handle-delete-frame).  Likewise, C-x 5 0 from the
> minibuffer frame does not delete it, again showing the error message
> (now from call-interactively).  With a non-minibuffer frame deletion via
> either the window manager or C-x 5 0 succeeds; then as soon as I click
> in the minibuffer frame, a new regular frame is created.

I think that's the intended behavior.  At least it was until Emacs 22.
And delete_frame depends on doing so as explained by this comment

	  /* We know that there must be some frame with a minibuffer out
	     there.  If this were not true, all of the frames present
	     would have to be minibufferless, which implies that at some
	     point their minibuffer frames must have been deleted, but
	     that is prohibited at the top; you can't delete surrogate
	     minibuffer frames.  */

> As for starting with emacs -q and the evalling (delete-frame nil t),
> this also does not make Emacs crash, but raises the error "Attempt to
> delete the only frame".

This is new behavior, obviously (it was there in the code, but commented
out).

> However, I apparently was mistaken in my post
> cited above: I thought evalling (delete-frame nil t) produced a core
> dump, like the attempt to delete the minibuffer frame did,

Could you (or someone else on GNU/Linux) post a backtrace for the
minibuffer deletion case?

> but I cannot
> reproduce that with the unpatched Emacs, so I must have been confused
> about the source of the core file (which I since deleted).  Instead,
> evalling (delete-frame nil t) in the unpatched Emacs simply kills Emacs,
> verified under gdb ("Program exited normally.").  Sorry for misreporting
> this yesterday.

That's what Emacs 22 did in that case - exit normally.  But Emacs 22 did
_not_ offer to save any unsaved buffers, so you might have lost some
work.  Does it offer to save buffers on your Emacs 23?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.