[8983] in Athena Bugs
Re: emacs/edsc spin
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Feb 17 15:58:38 1992
Date: Mon, 17 Feb 92 15:57:39 -0500
From: tytso@Athena.MIT.EDU (Theodore Ts'o)
To: ckclark@MIT.EDU
Cc: bugs@Athena.MIT.EDU, bug-discuss@Athena.MIT.EDU, jefft@Athena.MIT.EDU,
In-Reply-To: Calvin Clark's message of Mon, 17 Feb 92 09:16:21 -0500,
Reply-To: tytso@Athena.MIT.EDU
Date: Mon, 17 Feb 92 09:16:21 -0500
From: Calvin Clark <ckclark@mit.edu>
In other words, if for some reason edsc does not return its full output
soon, the process filter will never set `discuss-in-progress' to `nil',
and emacs will stay spinning in this while loop, because that's what
it's being told to do. One way to solve this problem is to explicitly
put timeouts in edsc, so that it won't keep emacs waiting too long.
Another solution is to use the "timer" package to allow emacs to control
the edsc timeout itself.
Well, edsc shouldn't be keeping the parent process waiting, unless
events out of its control (like your AFS or NFS server croaking) happen,
and there's not much you can do in that situation.
There are occasionally problems were edsc and (the old version of) the
Emacs lisp code get out of sync; that is probably what is going on.
When that happens, they can be easily fixed by typing ^G to abort the
discuss command, and then type "M-x discuss-restart" which restarts the
edsc process, as Marc noted.
The other thing you can do is to try the version of discuss.el which is
found in /mit/discuss/source/edsc/discuss.el. That's the version which
I use, and it is much less prone to these sorts of errors. (Basically,
the version in the Athena release attempts to do a lot of asynchronous
processing to do the cache management, and Emacs Lisp just isn't very
good at dealing with asyncronous processing. The new version uses the
new cache management code which is built into edsc, and so is much more
robust.)
This new version of discuss.el should probably go into the 7.3 release.
- Ted
