From xemacs-m  Sun Mar 16 16:05:40 1997
Received: from atreides.eng.mindspring.net (atreides.eng.mindspring.net [207.69.183.11])
	by xemacs.org (8.8.5/8.8.5) with SMTP id QAA06747
	for <xemacs-beta@xemacs.org>; Sun, 16 Mar 1997 16:05:40 -0600 (CST)
Received: (qmail 4796 invoked by uid 52477); 16 Mar 1997 22:05:10 -0000
Sender: sj@atreides.eng.mindspring.net
To: xemacs-beta@xemacs.org
Subject: Redisplay or specifier bug?
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sj@eng.mindspring.net>
Date: 16 Mar 1997 17:04:50 -0500
Message-ID: <yviaohcjv6g9.fsf@atreides.eng.mindspring.net>
Lines: 42
X-Mailer: Gnus v5.4.25/XEmacs 20.1

Eval the following in an xemacs -q and watch your xemacs shrink to
nothingness. 

(while t
  (set-specifier menubar-visible-p nil)
  (sit-for 0)
  (set-specifier menubar-visible-p t)
  (sit-for 0))

The shrinkage itself might not be a bug, though it's a bit
counterintuitive, since the new menubar is simply occupying screen
estate that belongs to the app.  A variable to force menubars to
appear by growing the XEmacs window would be nice.

However, if you omit either sit-for, redisplay stops after one pass
through the loop.  Why doesn't one suffice?  This seems like a bug to
me.  I haven't downloaded the latest beta and David's fixes might have
cured this already.  If so, apologies.

Further, XEmacs then gets into a state where trying to invert the current
menubar visibilty fails unless you do it a number of times.  Ugh, not
very clear -- for eg., if you C-g into a state where the menubar isn't
visible and then eval the second set-specifier above, the menubar
doesn't reappear.  Now, eval both set-specifiers again and it reappears.

Hmm, this just in:

(let ((n 0))
  (condition-case nil
      (while t
	(set-specifier menubar-visible-p nil)
	(sit-for 0)
	(set-specifier menubar-visible-p t)
	;(sit-for 0)
	(incf n))
    (quit (message "iters: %d" n))))

So, without one of the sit-for's, we can destroy/create the menubar
any number of times without shrinking more than one line.  Having the
shrinkage conditional on redisplay seems buggish.

-Sudish

