* Mark Harig 49FFD174.1000804@aim.com Wrote on Tue, 05 May 2009 01:41:08 -0400:
| Steven E. Harris wrote: |> Sorry, I wasn't clear. What I meant regarding CLISP is that if I |> start up its REPL from a shell, just running CLISP bare outside of |> SLIME, *standard-output* does appear in the CLISP REPL. When I run |> SLIME over CLISP, *standard-output* does /not/ get echoed to SLIME's |> REPL. The only way to see *standard-output* is to visit the |> *inferior-lisp* buffer. | | I see the behavior that you describe in my configuration, too. I | added the following line to ~/.swank.lisp to restore the earlier | behavior: | | (setq SWANK:*GLOBALLY-REDIRECT-IO*' t)
I think the idea behind Helmut's silence on this question is that he wants to encourage the use of GLOBALLY-REDIRECT-IO T instead of fixing the issues in design. This is not a good idea when you want to decouple the lisp from emacs.
Also there are bugs in the implementation: if you drop your connection slime and your current lisp image will become unusable with SLIME. To reproduce:
1. M-x slime-disconnect 2. M-x slime (or however you started it) Emacs asks: Create an additional *inferior-lisp*? (y or n) Answer `n'
You are dropped into the debugger with the following error.
'---- | Streams already redirected. | | Restart actions (select using :continue): | 0: retry assertion. | 1: Return to Top Level (an "abort" restart). | `----
The problem is that an ASSERT fails in SWANK::INIT-GLOBAL-STREAM-REDIRECTION.
<rant>
Earlier I have noticed on this list (and mentioned) the problems with the SWANK Emacs<->Lisp implementation especially with CMUCL in the face of errors.
After 4-5 years of development on slime, these issues have still not been fixed. A robust minimally-intrusive interaction between ephemeral emacsen and a long lived lisp is still not there.
Instead SLIME's implementation of the network and interaction has gotten more and more complicated and harder to work around. Debugging timing bugs which cause connections to be dropped are my latest example.
This growth in complexity contrasts sharply with Helmut's arguments in removing of basic functionality in elisp (such as control over filename completion, say), or not binding *read-eval* to NIL when READing the ChangeLog file. Helmut's arguments are that these complicate slime and make it harder to maintain.
-- Madhu