[slime-devel] REPL mode

[Helmut Eller]

Hi,

I've committed the beginnings of a comint-less REPL.  Here are some
thoughts.  

This is a proof of concept, to see if our own REPL is actually better
than the (not-so-) inferior-lisp mode.

The REPL is activated in the in idle-state and shares the buffer with
the other (redirected) output.  Some markers track the prompt, the
user input, and the beginning of the output.  The current design
doesn't maintain any state on the Lisp side (we probably should do
that, e.g., for things like *, **, *** etc.).

Some not so nice things about the new REPL:

 - since I didn't use comint I had to implement the history management
   myself.

 - prompting is triggered by the activation event of the idle state.
   This means the prompt is printed before we can print the result and
   we have to go back and insert the result before the prompt.  Also
   we have to check on every idle-state activation event, if we
   actually need insert a prompt (to avoid many unneeded prompts).

 - slime-space can produce output and cause a new prompt.  This can
   happen when CMUCL emits warnings during the first coercion a
   symbol to a function.

There is currently no good input handling, e.g, when the Lisp side
calls read-char on the redirected input stream, Emacs just reads a
line from the minibuffer.  My plan was to switch the keymap in the
repl buffer when the Lisp side request input.  The other keymap
doesn't behave like a repl, but send the input more or less
uninterpreted to the Lisp side.  Not sure how to implement this though.
Since I'm not using the repl all that much I'm not sure if it is
worth the trouble.

There are also problems with output buffering, e.g., when you evaluate
(labels ((foo () (foo) t)) (foo)) in the listener, CMUCL puts you in
the (tty-) debugger, but you can't see it because the output is
buffered somewhere.

The nicest thing about this repl is the integration with our debugger.
The ugliest thing is the complexity that is needed for better input
redirection.

Helmut.