在自定义 REPL 中的 Slime 自动文档
我使用 SLIME 和 EMACS for Common LISP 以及 SBCL 编译器。 SLIME 的自动文档功能（函数参数显示在迷你缓冲区中）运行良好。
但是，当我执行如下所示的自定义 REPL 时：
(defun game-repl ()
(let ((cmd (game-read)))
(unless (eq (car cmd) 'quit)
(game-print (game-eval cmd))
(game-repl))))
autodoc 功能不再起作用。不在 LISP 缓冲区中，也不在我的自定义 REPL 中。可能是因为 SBCL 进程正忙于我的 REPL（等待输入）并且无法与 SLIME 通信。
当我使用 Cu Mx slime 启动另一个 SBCL 进程后，自动文档功能再次起作用，但仅限于 LISP 缓冲区。
那么，有没有办法在我的自定义 REPL 中获取 SLIME autodoc？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您得出的结论是正确的，即 swank 后端（在您的 sbcl 进程中）正忙。 IIRC slime 具有同步和异步命令，并且您的 game-repl 将是一个同步命令，不允许异步文档命令到达后端 - 相比之下，在编写常规命令时slime REPL 中的命令，后端空闲，因此 doc 查询可以通过。
但请原谅我也想知道您在这种特殊情况下所做的是否有意义 - 自定义 REPL 的目的大概是以下之一或两者：
和无论哪种情况，自定义 REPL 的输入可能并不等同于 slime 可以自动为您生成文档的常规代码。
可能的选择是提供一个有限的“游戏”命名空间，您可以在其中玩常规的 slime REPL，然后还提供一个单独的面向生产的 REPL 和一个仅允许访问该命名空间中的符号的读取器？ （这里有关于 common-lisp 沙箱的讨论。）
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-replwould 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:
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.)