Lynn Quam quam@ai.sri.com writes:

I think the solution to the problem with my READ-EVAL-PRINT-LOOP is to not use SLIME-RESET, instead define the new function:

slime-reset was indented as a debugging tool for SLIME itself. It's primarily needed when the Lisp process dies for some reason but and Emacs has still some continuations or sldb buffers for the Lisp. E.g. slime-reset it's often needed when re-running the test suite without restarting Emacs.

(defun slime-repl-reset () (interactive) (setf (slime-rex-continuations) '()))

This is not much different from slime-reset. But if you cancel the continuations, you shouldn't be surprised to get error messages later. The error messages should be a bit differently than what you wrote in the other mail, it should be something like "Unexpected reply: ...". I have no idea where other messages comes from.

This appears to work, but I would be happier my Lisp REPL could inform SLIME when it starts. What is the protocol for Lisp invoking a function in EMACS?

There's no "official" way. There's only a backdoor: swank::eval-in-emacs. It just calls a function in emacs; it doesn't wait for the result.

The problem is that REPL is started in the SLIME-REPL buffer and REPL never returns. thus there is a pending slime-rex-continuation that apparently prevents slime-autodoc-mode from doing its thing.

We try to be a bit careful when sending stuff which is not explicitly requested by the user. autodoc-mode and slime-space are by default disabled if Lisp is already doing something. These things are disabled, because we don't want to interrupt Lisp for unimportant things. That wouldn't be a problem for multi-threaded Lisps, but it is a bit problematic in combination with the :sigio and :fd-handler communication styles.

I've added a new variable slime-inhibit-pipelining to make this customizable. If you set it to nil, slime-autodoc-mode should also work while Lisp is reading input from Emacs.

Helmut.