[slime-devel] Re: `slime-repl-abort-read' bug?

[Helmut Eller]

* Taylor R Campbell [2006-11-24 20:55+0100] writes:

> `slim-repl-abort-read' ignores its two arguments and just pops
> `slime-read-string-threads' and `slime-read-string-tags'.  Is the Lisp
> system really assumed to request and to abort REPL reads in a LIFO
> manner, or is this a bug?

Yes, it's a bug.  But one could argue, that the current implementation
satisfies LIFO unless two threads read simultaneously from the same
stream [and that the stream should synchronize concurrent reads].

> Or is my understanding of the way SLIME's
> REPL read mode works bogus?

Well, the REPL read mode is more or less broken by design.  Currently,
the Lisp side essentially turns a read operation on a stream into an
RPC.  Emacs will then switch the REPL buffer into read mode, switch
back to normal mode after the user has entered some text, and return
the text to Lisp.  Obviously, the situation becomes horribly
complicated if the RPC gets interrupted.

A simpler approach would be this: like now the REPL buffer can be in
"normal mode" and in "read mode".  In normal mode the REPL buffer
communicates only with the REPL thread (i.e. sends expressions, waits,
and prints result).  In read mode, we only talk to a "buffer thread"
on the Lisp side.  The buffer thread basically buffers the input from
Emacs.  If other threads want to read input from Emacs, they ask the
buffer thread (instead of talking to Emacs).

When should we switch between normal mode and read mode?  I think it
would be quite intuitive, if we switch to read mode after we sent the
expression to the REPL thread and switch back to normal mode when we
receive the result.

With this design, we don't need to worry much about interrupts,
concurrent reads can be handled by buffer thread, and the
implementation the READ-CHAR-NO-HANG becomes straightforward.

The only thing left is to implement this idea in a Lisp without
threads.

Helmut.