Subject: bug#16967: frame related race condition

From: martin rudalics <[email-masked]>
Date: Mon, 10 Mar 2014 20:04:18 +0100

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