From xemacs-m  Mon Jan 13 23:12:25 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id XAA09045 for <xemacs-beta@xemacs.org>; Mon, 13 Jan 1997 23:12:24 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQbyki29097; Tue, 14 Jan 1997 00:12:25 -0500 (EST)
Date: Tue, 14 Jan 1997 00:12:25 -0500 (EST)
Message-Id: <QQbyki29097.199701140512@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org (XEmacs beta testers)
Subject: Re: automatic de-iconify in 20-b34 w/ byte-recompile-directory 
In-Reply-To: <199701140419.XAA17368@spacely.icd.teradyne.com>
References: <199701060128.UAA11198@spacely.icd.teradyne.com>
	<199701140419.XAA17368@spacely.icd.teradyne.com>

Vinnie Shelton writes:
 > This bug is still present in 20-b90:
 > 
 > In 20-b34, after starting "-no-init-file -q", I ran
 > byte-recompile-directory on the tm directory and I iconified
 > the frame.  The frame de-iconified itself!  The frame would
 > not stay iconified while the recompile was running.

Even without looking at the code, I can pretty much guess what's
going on here.  Each instance of byte-compile-file wants to show
its buffer of warnings and errors.  It calls display-buffer to
show it to you.  display-buffer notices that the buffer isn't
visible anywhere except in that iconified frame, so it
deiconifies the frame so you can see it.  You iconify the frame
again, and then another instance of byte-compile-file calls
display-buffer and the frame pops up again.

Not really a bug, just the law of unintended consequences at
work.

