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.