[slime-devel] Has anyone thought about implementing this?

[Helmut Eller]

* 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.