Xref: utzoo gnu.emacs.help:332 comp.emacs:9515
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ATHENA.MIT.EDU!bjaspan
From: bjaspan@ATHENA.MIT.EDU ("Barr3y Jaspan")
Newsgroups: gnu.emacs.help,comp.emacs
Subject: "Difficult elisp problem" solved.
Message-ID: <9011142000.AA22290@PORTNOY.MIT.EDU>
Date: 14 Nov 90 20:00:20 GMT
Sender: daemon@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: GNUs Not Usenet
Lines: 26


Well, I tried to run the elisp code while running emacs under a
debugger with breakpoints in the redisplay code, and guess what?  The
problem disappeared.

dingdingdingdingdingding

What does it mean when you are dealing with asynchronous events and
inserting breakpoints solves the problem?  Can you say RACE CONDITION?
I knew you could.

I still don't know exactly what was causing the problem, but it
clearly had something to do with the fact that the notice headers,
body, and terminator were all coming in as separate calls to the
filter function and confusing things -- putting in the (sleep-for 1)
or the breakpoint caused all three to batch up and get sent together,
and everything was happy.

Anyway, I rewrote the code to keep the currently-being-built notice in
a variable and only dump to the buffer when the terminator is
received.  This fixed the problem and made the code considerably
simpler to boot!

Thanks to everyone who sent in suggestions.

Barr3y