bug#16967: frame related race condition

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Mar 10, 2014 at 2:11 PM, martin rudalics <rudalics@gmx.at> wrote:

> should create a normally visible frame f.  The fact that this frame has
> its visibility set to zero at the time you `delete-frame' c indicates
> that we have a pretty awful bug.

Yes

> The implications of this are
> substantial because SET_FRAME_VISIBLE has to redisplay_other_windows and
> if that is not done, the consequences are not restricted to the toy
> scenario you gave.

I don't know what "toy scenario" are you refering to, but certainly

  emacs -Q
  M-: (make-frame '((visibility))) <RET>

is not a toy scenario *at all*. For one, it will prevent
frameset-restore to restore invisible frames (I could work around it,
but it'll be a hack).

> No.  But we apparently have the problem that Emacs on Windows thinks
> that a frame is invisible although it isn't.  And we have to find out
> where this notion of invisibility gets introduced - maybe it's easy to
> spot it, maybe, likely it's part of my pixelwise changes, and we can
> withdraw my "fix" soon.

I think bug#14841 is a clue that the visibility mismatch between Emacs
and the Windows wm predates your pixelwise changes.

>  But till then we have to live with the
> situation that on Windows invisible Emacs frames are visible :-(

I would certainly prefer that you reverted your last change. You're
fixing an occasional problem and introducing a perfectly repeatable
one.

   J