Two Things

[Bill.Chiles@CHILES.SLISP.CS.CMU.EDU]

So, I'd like to be in the loop on all mail concerning the RT port.  I want
to at least know where it is and what's happening, even if Rob feels
William has to find the bug or vice versa.  Maybe we should create a
mailing list for ourselves, so the three of us can track everything
regardless of Scott and undergrads.  Scott might argue everyone should see
this stuff, but I actually believe there's little reason for his seeing
most of it.  However, I do want to see it.  I have an MH alias I use to
send you two mail, so maybe you could cook up the same thing.  I also care
more about porting in general since I'm no longer resisting knowledge
acquisition concerning the system, Lisp, CS, the world, etc.

On the redisplay bug, I believe Rob's heuristic for going through redisplay
twice is seriously flawed.  Going through twice makes sure you get
exposures generated by region copies, but the after method does this
anyway.  Rob's solution does nothing to close the window the old code
closed that prevents events coming in that modify buffers just before going
into an input wait.  Rob considered this, but I believe his theory of
operation is wrong.

Try this:
       (loop
	 (when (setf key-event (dq-event stream))
	   (dolist (f (variable-value 'ed::input-hook)) (funcall f))
	   (return))
	 (invoke-scheduled-events)
	 (unless (or (system:serve-event 0)
		     (internal-redisplay))
	   (when nrw-fun (funcall nrw-fun t))
	   (let ((wait (next-scheduled-event-wait)))
	     (if wait (system:serve-event wait) (system:serve-event)))))

You execute INTERNAL-REDISPLAY, and it returns t indicating some window had
changed lines.  You go back to the top of the loop, check for input, check
for scheduled events, and call SYSTEM:SERVE-EVENT returning immediately.
Assume there were no events at this time.  Then you enter
INTERNAL-REDISPLAY again, just because you happened to update some window's
image before; note, we never before needed this extra pass through
redisplay that I'm aware of.

Now, you book over all the windows checking them, and sure enough
everything is up to date.  In fact, with all the listening for editor
input, none arrives ever, and suddenly we're done looping over all the
window and positioning the cursor.  Note, we just went through redisplay
finding no modified buffers or windows, so INTERNAL-REDISPLAY returns nil.
Also, since INTERNAL-REDISPLAY was modified to invoke the after method,
just before returning nil, we happend to get a stream op that dumped some
output in the typescript buffer.  In the above code fragment, we drop into
the UNLESS body and wait for some input.

I believe this is totally correct.

I also checked REDISPLAY-WINDOWS-FROM-MARK which you expect the stream op
to call since you expect the stream ops to force output when prompting.
This function says, "Oh, I'm *in-redisplay*, so I'll just return t."  Of
course, no matter how much the code that calls REDISPLAY-WINDOWS-FROM-MARK
continues calling it, that code will always be *in-redisplay*.  Therefore,
the prompt will never be displayed in Hemlock.  I did not check the calls
to REDISPLAY-WINDOWS-FROM-MARK to see if the called it repeatedly, but if
the code did, I suspect it would infinitely loop.

Now what to do about this.  The only thing I can think to do is what
William described formally.  We must make sure we pick up no further events
between the time we decide we are completely done redisplaying and the time
we wait for input.  I believe the only way to do this is to let the
input/event-handling loop call INTERNAL-REDISPLAY again as it used to do in
the presence of further events.  If these are exposure events, then fine;
it still works.

Secondarily, we need to figure out what Rob was trying to solve with his
hack: if some window was modified on this call to redisplay, tell someone
to call it again because maybe something got modified again.  I truly
believe Rob is comparing apples and chunks of iron found in Brazil, but I
don't know what glitch in redisplay he was trying to solve that led him to
that solution.

Bill