branch: externals/sly
commit ae4bbcaadc2b65d4f64c99b956c739372eeba1cc
Author: João Távora <[email protected]>
Commit: João Távora <[email protected]>
Don't force mREPL to use channel thread for everything
An mREPL thread's main function (if it exists) is to serve
:emacs-channel-send and reply with :channel-send. It can also serve
:emacs-rex requests, but those can normally be spawned in a new worker
thread.
Most implementations don't care, but Clasp, in particular, has what I
suspect to be a broken SLYNK-BACKEND:THREAD-ID implementation, and so
finding a specific thread by ID doesn't work so well. Since this
shouldn't hurt other implementations, stop setting the Elisp variable
sly-current-thread in the REPL, thus letting it have its default value
of t there.
* contrib/sly-mrepl.el (sly-mrepl-new): Don't set
sly-current-thread.
---
contrib/sly-mrepl.el | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/sly-mrepl.el b/contrib/sly-mrepl.el
index 90c1397..9c412bf 100644
--- a/contrib/sly-mrepl.el
+++ b/contrib/sly-mrepl.el
@@ -1013,7 +1013,6 @@ handle to distinguish the new buffer from the existing."
(with-current-buffer buffer
(sly-mrepl--read-input-ring)
(setq header-line-format nil)
- (setq sly-current-thread thread-id)
(set (make-local-variable 'sly-mrepl--remote-channel) remote)
(unwind-protect
(run-hooks 'sly-mrepl-hook 'sly-mrepl-runonce-hook)
