0
votes

I'm using SLIME and EMACS for Common LISP, with the SBCL compiler. The autodoc feature of SLIME, where function arguments are shown in the minibuffer, works fine.

But when I execute a custom REPL like the following:

(defun game-repl ()
  (let ((cmd (game-read)))
    (unless (eq (car cmd) 'quit)
      (game-print (game-eval cmd))
      (game-repl))))

The autodoc feature doesn't work anymore. Not in LISP buffers, and not in my custom REPL. Probably because the SBCL process is busy with my REPL (waiting for input) and can't communicate with SLIME.

After I start another SBCL process with C-u M-x slime, the autodoc feature works again, but only in LISP buffers.

So, is there a way to get the SLIME autodoc in my custom REPL?

1
I've had this happen on several occasions. Sometimes, it seems as though the state between SWANK, Emacs and the REPL is screwed up somehow.Elias Mårtenson
Did you try to start your custom REPL in a thread ? i.e. with bordeaux-threads (bordeaux-threads:make-thread #'game-repl)Daimrod

1 Answers

2
votes

I think you're correct in concluding that the swank backend (in your sbcl process) is busy. IIRC slime has both synchronous and asynchronous commands, and your game-repl would be a synchronous command that wouldn't allow the asynchronous documentation commands to get through to the backend -- in contrast, while composing a regular command in the slime REPL, the backend is idle, so doc queries can get through.

But please forgive me for also wondering whether what you're doing in this particular case makes sense -- the purpose of a custom REPL is presumably one or both of:

  • Expose a limited or synthetic command set
  • Provide non-standard control/syntax structures

and in either case, input to the custom REPL might not be equivalent to regular code that slime could auto-doc for you.

Might an option be to provide a limited "game" namespace in which you could play around in the regular slime REPL, and then also provide a separate production-oriented REPL with a reader which would only allow access to symbols in that namespace? (There's a discussion of common-lisp sandboxing here.)