Here is a batch-mode reply to some survey comments:
Bill_Clementson@peoplesoft.com writes:
Which Lisp versions do you use SLIME with?
Allegro 6.2 and 7.0beta, LispWorks 4.3, CLISP 2.33, and ABCL (cvs) - all on Win2000
[...]
bug: the "v"iew source option in sldb doesn't work for any implementation I'm using
Not even in LispWorks? It should work there, with defun-granularity. Likewise ACL in CVS now.
Andras Simon andras@renyi.hu writes:
On the features side: I think that RET should do newline and indent in a source buffer (who would want to write lisp code without indentation?). I use
That is most reasonable, though the usual Emacs Way is to have C-j do this instead of RET. You can rebind RET to `newline-and-indent'.
An easy way to toggle (with no questions asked) between source files and the REPL (or REPLs) with the same (simple) key chord. Ideally, with a prefix argument, it would offer the recently visited source files or REPLs, depending on whether we're in a REPL or a source file.
Try the `slime-selector' command. Not exactly what you're asking for, but perhaps pretty close.
Also, multiple REPLs to the same lisp image (like in eli) would be nice. (I'd probably switch from eli to slime with acl.)
The internals actually support this. You could do:
(swank:create-server :dont-close t)
To start a server that stays open after the first connection, then open multiple connections to it using `M-x slime-connect'.
[I would quite like to delete the internals that make this possible, but I don't think I'll get away with that :-)]
"Thomas F. Burdick" tfb@OCF.Berkeley.EDU writes:
The compilation notes buffer always pops up when there is exactly one STYLE-WARNING (usually a redefinition warning, ug), but not when there are some notes, which I might actually want to see.
Yes, that shits me too. The reason it pops up is that those "redefining:" style warnings are signalled without any source-path information, so we don't know where to annotate them and fall back to popping up the buffer.
I've hacked those warnings out of my local SBCL and started a nagging campaign on Christophe.
Finally, there's no ASDF system editor.
What would such a beast look like?
Christophe Rhodes csr21@cam.ac.uk writes:
I would like to see a little more work on coordination between slime and implementations (not just SBCL, though obviously that's where my focus is). There's a load of complicated code in swank-sbcl.lisp that I'd just love to break on the grounds that no-one asked me for PERMISSION to use MY symbols... on the other hand, I can imagine hordes of angry lispers turning up in London (or Cambridge, at the weekend ;-) and lynching me if I've broken their SLIME 1.0.
Christophe and I have talked about this off-list. We've suggested that for whatever internal SBCL functions we're still calling towards the release, we'll call them indirectly via an "sb-slime"-or-such package which will be part of SBCL. This level of indirection means that the SBCL guys can change the internals that we're accessing and still be SLIME-1.0 compatible so long as they update sb-slime in terms of the new internals.
We could also do this with for any other Lisps that're interested. Of course as much as possible we'd prefer to switch to using public interfaces instead of digging into internals.
Glenn Ehrlich glenn.ehrlich.lists@cox.net writes:
I'd like to see viewing source from a stack frame try and go to the actual line of source code, instead of just the function.
This is a per-backend thing. In CMUCL you should get the exact source form within the definition. It would be very nice to figure out how to do this for other implementations.
-Luke