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 -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp