GNU bug report logs - #16967
frame related race condition

Previous Next

Full log

Message #26 received at 16967 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16967 <at> debbugs.gnu.org
Subject: Re: bug#16967: frame related race condition
Date: Mon, 10 Mar 2014 15:48:29 +0100

On Mon, Mar 10, 2014 at 2:11 PM, martin rudalics <rudalics <at> 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

Previous Next

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