* Fred Gilham [2005-12-02 22:11+0100] writes:
Has anyone thought of doing this? Would it be hard to do if someone wanted to try it as a first slime implementation project?
Output to streams is a bit messy with SLIME. Currently there are two ways to do that:
1. the so called "dedicated output stream", which opens a separate network connection for stream output (in addition to the connection for ordinary messages). On the Emacs side, a process filter inserts everything from that connection in the REPL buffer. If you want to go with that apprach you probably need a different connection for each stream.
2. our protocol has a (:write-string STRING) message and output is multiplexed over the same connection as the all other messages. With that appraoch you could extend the message to include some identifier for the stream. The identifier could then be mapped to the buffer/marker where the output should go.
Explicit protocol messages are not as fast, but are easier to work with, because the output is always synchronized with other messages. With both variants you need decide what to do if the user kills the buffer for the output and things like that. The hardest part is probably the stream/identintifier/buffer mapping. Doesn't sound that hard. If it's worse the effort is a different question.
Or is it already done as an undocumented feature?
No.
Below are some thoughts about input streams, but that's probably more confusing than helpful at the moment.
Input from streams works currently as follows: the Lisp processes requests input from Emacs with a :read-string messages and waits until Emacs replies with with the corresponding :emacs-return-string. I think those messages could also be extended with a stream identifier.
But this request/reply approach is a bit problematic because LISTEN doesn't work as it should. It seems that Emacs should be able to "push" input to the Lisp process at any moment, not only when the Lisp side requests it. (That would also bring us closer to our goal: a stateless protocol.) Anyway, a working LISTEN is a good test for a input stream design.
A related problem is the REPL. Our listener doesn't read expressions from the input stream but Emacs sends a "listener-eval" message with the expression (as string) and waits for the result. So, most of the time the REPL doesn't use the stream machinery (only the stream to encode/decode protocol messages). That's nice when creating a new backend because the REPL will work very early. I'm not sure if we could implement it the other way. If we block for input we still need to process protocol messages, which tends to be a bit funky in single threaded Lisps. It would probably also need extra work to keep the REPL responsive while debugging.
Helmut.