bug#16967: frame related race condition

[martin rudalics]

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

Really?  I was just starting to think otherwise.

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

The one of this bug report which IIUC even you consider "an occasional
problem" ;-)

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

OK.  Then I have a motivation to revert it.

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

I think that I misjudged the severity of the problem.  Drew's latest
reports hint at some mysterious behavior which I haven't been able to
understand yet so I'm suspecting potential culprits around every corner.

> I would certainly prefer that you reverted your last change.

Done.

> You're
> fixing an occasional problem and introducing a perfectly repeatable
> one.

Sorry for the inconvenience.

martin