bug#1450: w32_reset_fringes

[martin rudalics]

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