Alan Ruttenberg alanr-l@mumble.net writes:
I have committed some changes that I'm a little insecure about, so there is a bit of a hurdle to use them. Feedback desired. Essentially I've extended the recent repl output mechanism to arbitrary objects you choose to print that way.
"In the long run every program becomes rococo - then rubble." -- Alan Perlis
(defun slime-open-stream-to-lisp (port) (let ((stream (open-network-stream "*lisp-output-stream*" (slime-with-connection-buffer () @@ -2539,9 +2574,19 @@ (when slime-kill-without-query-p (process-kill-without-query stream)) (set-process-filter stream 'slime-output-filter)
- (set-process-coding-system stream
slime-net-coding-systemslime-net-coding-system)
- (when slime-repl-enable-presentations
(require 'bridge)(defun bridge-insert (process output)(slime-output-filter process (or output "")))(install-bridge)(setq bridge-destination-insert nil)(setq bridge-source-insert nil)(setq bridge-handlers (list* '("<" . slime-mark-presentation-start)'(">" . slime-mark-presentation-end)bridge-handlers))(set-process-coding-system streamslime-net-coding-systemslime-net-coding-system))
This doesn't look like the right place to do it. slime-open-stream-to-lisp is only called if the dedicated output stream is used. If the dedicated stream is disabled the markers will not be scanned. You could do the scanning in slime-output-string.
The more fundamental question is why you use a special protocol. Why can't you use the existing infrastructure and send the string with the id as a list like we do in the inspector?
Helmut.