From xemacs-m  Wed Mar 12 16:44:27 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id QAA13939
	for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 16:44:24 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id OAA26567 for <xemacs-beta@xemacs.org>; Wed, 12 Mar 1997 14:44:24 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id OAA01171; Wed, 12 Mar 1997 14:46:30 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: 20.1-b6: sit-for and accept-process-output
References: <QQcgmy07372.199703120600@crystal.WonderWorks.COM> 	<rvsp21t4bp.fsf@sdnp5.ucsd.edu> <QQcgpe22959.199703122030@crystal.WonderWorks.COM>
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: 12 Mar 1997 14:46:29 -0800
In-Reply-To: Kyle Jones's message of Wed, 12 Mar 1997 15:30:46 -0500 (EST)
Message-ID: <rvsp20enju.fsf@sdnp5.ucsd.edu>
Lines: 37
X-Mailer: Gnus v5.4.24/XEmacs 19.15

Kyle Jones <kyle_jones@wonderworks.com> writes:

> I managed to catch one of these spins in the debugger.
> accept-process-output is being called and it is checking
> recsursive_sit_for, finding it to be non-nil and is returning
> immediately.  VM's POP code calls accept-process-output with a
> non-nil second arg, so this immediate return is bogus behavior
> according to the documentation for accept-process-output.

Ok, then that patch will fix it.  It turns out that the documentation
for accept-process-output, sleep-for and sit-for have not been
sufficient for defining what the operations do.  So, at each step of
trying to restore sanity to these operations, I've been adding a
collection of regression tests which help to define the ``correct''
behaviour amongst the many possible ones.  Hopefully this will cut down
on problems like this in the future, since people who try to introduce
new features or fix bugs can test the code w/o waiting 2 weeks to hear
that lazy-lock & shell-mode interact badly, etc.

> C-g is not treated the same as SIGINT in all cases.  See Fnext_event.
> Sometimes it is read as a normal key and acted upon via a keymap.  If
> this happens when a spin begins, the C-g's are buffered until the
> loop is broken.  Sending a SIGINT kicks XEmacs out of the loop and
> then you'll see repeated Quit messages for all the bufferd C-g's
> (Which itself is interesting since I thought a C_g instigated quit
> discarded buffered command input.  Perhaps not in the case of C-g's
> treated as ordinary keystrokes.)

Yes, you're right, and a QUIT check isn't being done at a reasonable
place in this case.


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

