From xemacs-m  Mon Mar  3 13:34:02 1997
Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA20550
	for <xemacs-beta@xemacs.org>; Mon, 3 Mar 1997 13:34:01 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA04832 for <xemacs-beta@xemacs.org>; Mon, 3 Mar 1997 11:33:50 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA21021; Mon, 3 Mar 1997 11:36:06 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: [19.15b95]: Process output doesn't redisplay during sit-for
References: <9703031332.AA12134@mail.esrin.esa.it>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 03 Mar 1997 11:36:05 -0800
In-Reply-To: David Byers's message of Sat, 25 Jan 1997 13:44:45 +0100
Message-ID: <rvbu903h0a.fsf_-_@sdnp5.ucsd.edu>
Lines: 33
X-Mailer: Gnus v5.4.15/XEmacs 20.1

Simon Marshall <Simon.Marshall@esrin.esa.it> writes:

> In XEmacs 19.14 and below (and presumably earlier 19.15 betas?) process
> output while in a sit-for provoked a redisplay.  Now it does not:

	David Byers submitted a patch around b90->b91, which explicitly
introduced the behaviour you are now seeing.

David Byers <davby@ida.liu.se> writes:

> > [From: David Moore <dmoore@UCSD.EDU>]
> > 	I noticed the potential for this bad recursive behaviour when I
> > fixed the previous sit-for bug (that fix didn't change these
> > semantics).  I was going to try to solve this problem, but it's not
> > totally clean, and I hoped it wasn't biting anyone.
> 
> Well, it sure bit me.
> 
> Firstly, I think I can fix sit-for and sleep-for reasonably cleanly. By
> adding a queue similar to command_event_queue for process events,
> Fsit_for and Fsleep_for can defer processing of these events to after
> they finish, as is done with command events. This appears to work well.

	I didn't really look at this, since I was out of town a lot
during that time, but one of the uses of sit-for is to allow scheduled
timer events to proceed.  This issue is slightly different than the one
mentioned by Simon, but also needs to work correctly.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

