Luke Gorrie luke@bluetail.com writes:
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
I don't think we've discussed a UI that would support what Dirk wants. It sounds like separate threads for REPL and lisp-mode commands. I suppose ELI works like this with thread-per-request.
My UI thoughts so far have been limited to "SLIME uses one thread for requests, but other threads can also do user input/output and enter the debugger". That way SLIME could be used to debug multithreaded programs. I don't know how to handle I/O from threads or how to keep order in Emacs if lots of threads go mad in Lisp - this seems like the main area for experimentation.
Thoughts?
I'm not sure I understand what you mean by "lots of therads go mad in Lisp". Do you mean, they generate a lot of output. I assumed that each Lisp thread would have a buffer in emacs where it's output went. But maybe you're talking about something else.
BTW, this morning I got some multithreading working in CMUCL with the new connection-per-thread model. This is different to the previous incarnation in that different threads can talk to Emacs at the same time ("Peter Siebel style" :-)).
:-)
-Peter