GNU bug report logs - #16967
frame related race condition

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 16967 <at> debbugs.gnu.org
Subject: Re: bug#16967: frame related race condition
Date: Tue, 11 Mar 2014 09:07:36 +0100

>> Lately I frequently noticed that an Emacs frame that was for some time
>> hidden by other applications and subsequently became exposed by deleting
>> their windows was not redrawn and I would like to know whether this was
>> the reason.  ISTR that others noted the same or a similar misbehavior.
>
> My "redisplay bit" changes of a few months back introduced such bugs.
> I haven't seen such problems for a while now, so I think I've caught all
> the problems, but maybe I still missed some.
>
> Part of the change is that previously iconified/invisible frames where
> redisplayed right away (i.e. their glyph matrices were kept up-to-date),
> whereas now they're not.  Which means that when they're uniconified or
> made visible, we have to first set windows_or_buffers_changed to
> REDISPLAY_SOME, to make sure that the subsequent redisplay doesn't
> forget to look at them.

In all cases I observed this, the Emacs frame was neither invisible nor
iconified before, hence there was no uniconifying or making it visible
involved.  And since I don't recall observing this problem on GNU/Linux,
I'm quite convinced that it's merely Emacs mishandling frames obscured
for some time on Windows.

martin

Previous Next

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