[slime-devel] Re: SLIME User Survey

Luke Gorrie luke at bluetail.com
Sat Jun 19 21:42:02 UTC 2004


Here is a batch-mode reply to some survey comments:

Bill_Clementson at 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 at 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 at 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 at 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 at 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





More information about the slime-devel mailing list