From xemacs-m  Mon Jan 13 23:49:45 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id XAA09456 for <xemacs-beta@xemacs.org>; Mon, 13 Jan 1997 23:49:42 -0600 (CST)
Received: (from steve@localhost)
          by altair.xemacs.org (8.8.4/8.8.4)
	  id VAA04429; Mon, 13 Jan 1997 21:59:35 -0800
Sender: steve@xemacs.org
To: xemacs-beta@xemacs.org
Subject: Re: automatic de-iconify in 20-b34 w/ byte-recompile-directory
References: <199701060128.UAA11198@spacely.icd.teradyne.com> 	<199701140419.XAA17368@spacely.icd.teradyne.com> <QQbyki29097.199701140512@crystal.WonderWorks.COM>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Kyle Jones's message of Tue, 14 Jan 1997 00:12:25 -0500 (EST)
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII
Date: 13 Jan 1997 21:59:33 -0800
Message-ID: <m2vi90bxve.fsf@altair.xemacs.org>
Lines: 48
X-Mailer: Red Gnus v0.80/XEmacs 20.0

Kyle Jones writes:

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

As Kyle points out, this is a feature.

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

Start up a new XEmacs, evaluate this in the scratch buffer, and
quickly iconify through the window manager to demonstrate that it is
coming from the call to display-buffer.

(progn
  (sit-for 10)
  (display-buffer "*scratch*"))

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

It's pushing my limit.  I personally hate when programs change a
window setup I've manually arranged.

There is a bug if this is intended to guarantee visibility.  Repeat
that test with a virtual window manager like olvwm.  While the frame
is still iconified, switch virtual consoles.  I see the frame
deiconify in the departed virtual console, but not in the current
console.  (I consider olvwm's treatment correct, it would annoy me
even more if the frame transported itself across virtual consoles).

Much of the XEmacs frame code is broken in a virtual window manager
environment, and unfortunately not all of it can be disabled :-(.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
Today's environment is 20.0 XEmacs Lucid (beta91) and Red Gnus v0.80

