I finally got around to trying SLIME, by downloading the tarfile at: http://www.common-lisp.net/project/slime/slime-1.0alpha.tar.gz
I must say, I am very impressed. It looks like Slime aims to fix almost all of my minor annoyances when using cmucl/ilisp. In particular, I like the way that it opens a different buffer to deal with errors/breaks/etc, rather than dumping a screen full of stuff into the repl buffer.
But a few things that I noticed:
I like to put testing sexprs in the files that I am working on (I put them in all in a #| |# commented region so that I can evaluate them when I want, but they don't evaluate when I compile/load the file). In ilisp I evaluate them with C-z e, and I gather that the slime equivalent is C-x C-e.
The problem is, slime puts the output in the minibuffer. (Ok, ilisp can be set up to do this as well, but I have it disabled.) Often I am printing out a representation of a large enough data structure that the output doesn't even fit in the available space. Also, the way that it disappears as soon as a key is pressed prevents me from refering to it later after I have checked/tested something else. The obvious workaround is to copy/paste the sexpr into the repl buffer, but I do this so often (at least on my current project) that this would be a serious pain.
For me, the ideal way for this to work would be for there to be a variable that controls whether or not evaluation output goes to the minibuffer or the repl (Or is there one already? I put a bit of effort into looking and couldn't find anything...). A different evaluation command (maybe: slime-eval-last-expression-in-repl) would also work.
I also noticed a couple of indentation issues: (ok, I admit it; I went out of my way to see how slime would indent different things ;-) )
CL> (defmacro test (a &body b) (list* '+ a b)) TEST CL> (test 1 2) 3
Which - as advertised - actually does the right thing (ilisp most certainly doesn't). But,
CL> (with-accessors ((a b)) c ...)
and
CL> (defgeneric test2 (a) (:method-combination progn)) #<Standard-Generic-Function TEST2 (0) {48B3C389}> CL> (defmethod test2 progn ((object a)) ...)
still arn't right. (But no loss there; ilisp does exactly the same thing...)
The only other thing is that the &body indentation doesn't work in the lisp buffers created by opening a file. But I suspect that is because I still have ilisp installed, and it is clobbering whatever slime does. (Is there a workaround?)
Anyway, I hope this helps. Slime has impressed me enough that I'm quite certain that I'll switch to it sometime in the future; the only thing stopping me at the moment is the minibuffer issue. (If nothing else, I'll come up with a fix myself when I have more time; my honours project is all-consuming at the moment.)
Regards,
Iain
iain.little@gmail.com wrote:
The problem is, slime puts the output in the minibuffer. (Ok, ilisp can be set up to do this as well, but I have it disabled.) Often I am printing out a representation of a large enough data structure that the output doesn't even fit in the available space. Also, the way that it disappears as soon as a key is pressed prevents me from refering to it later after I have checked/tested something else. The obvious workaround is to copy/paste the sexpr into the repl buffer, but I do this so often (at least on my current project) that this would be a serious pain.
For me, the ideal way for this to work would be for there to be a variable that controls whether or not evaluation output goes to the minibuffer or the repl (Or is there one already? I put a bit of effort into looking and couldn't find anything...). A different evaluation command (maybe: slime-eval-last-expression-in-repl) would also work.
I completely agree. It can be very useful for output from eval-last-expression to go into the REPL buffer.
Another useful command would insert the output from eval-last-expression into the current-buffer in the same manner as slime-eval-print-last-expression does with the *slime-scratch* buffer.
iain.little@gmail.com writes:
I like to put testing sexprs in the files that I am working on (I put them in all in a #| |# commented region so that I can evaluate them when I want, but they don't evaluate when I compile/load the file).
[...]
The problem is, slime puts the output in the minibuffer.
The interactive-eval family of of commands (C-x C-e, C-c M-:, etc) will now output to the REPL if you give them a prefix argument, so e.g. C-u C-x C-e.
Without a prefix they now print their results via `slime-message' rather than `message', meaning they can use a temporary buffer or a typeout frame for multi-line results.
I also noticed a couple of indentation issues: (ok, I admit it; I went out of my way to see how slime would indent different things ;-) )
[...]
Which - as advertised - actually does the right thing (ilisp most certainly doesn't). But,
CL> (with-accessors ((a b)) c ...)
Usually we exclude with-* and def* from indentation-learning because Emacs already does their indentation specially. Still, Emacs doesn't always get it right, so now you can customize `slime-conservative-indentation' to turn that off.
CL> (defgeneric test2 (a) (:method-combination progn)) #<Standard-Generic-Function TEST2 (0) {48B3C389}> CL> (defmethod test2 progn ((object a)) ...)
I'll leave this one to someone who understands CLOS :-)
The only other thing is that the &body indentation doesn't work in the lisp buffers created by opening a file. But I suspect that is because I still have ilisp installed, and it is clobbering whatever slime does.
I'd avoid loading ILISP because it binds a bunch of keys directly in lisp-mode, so once loaded it's "there". I'm not sure if this has any side-effects beyond just introducing non-SLIME keys in lisp buffers.
This indentation problem is most likely because lisp-mode isn't configured to use common-lisp indentation style. There's now an easy way to do this from ~/.emacs: (slime-setup). That configures lisp-mode-hook to enable slime-mode and to use common-lisp indentation. You can instead use (slime-setup :autodoc t) to also enable the autodoc mode.
Anyway, I hope this helps.
Yeah. It's very helpful to mention the "little things" since if it's bothering you then it's probably bothering a bunch of other people too.
-Luke
On Fri, 16 Jul 2004 23:48:20 +0200, Luke Gorrie luke@bluetail.com wrote:
iain.little@gmail.com writes:
The problem is, slime puts the output in the minibuffer.
The interactive-eval family of of commands (C-x C-e, C-c M-:, etc) will now output to the REPL if you give them a prefix argument, so e.g. C-u C-x C-e.
Cool - thanks!
Which - as advertised - actually does the right thing (ilisp most certainly doesn't). But,
CL> (with-accessors ((a b)) c ...)
Usually we exclude with-* and def* from indentation-learning because Emacs already does their indentation specially. Still, Emacs doesn't always get it right, so now you can customize `slime-conservative-indentation' to turn that off.
CL> (defgeneric test2 (a) (:method-combination progn)) #<Standard-Generic-Function TEST2 (0) {48B3C389}> CL> (defmethod test2 progn ((object a)) ...)
I'll leave this one to someone who understands CLOS :-)
This is just another def* case that emacs doesn't get right; it assumes that any qualifiers are keywords. But this isn't true if you arn't using the standard method combination, so it doesn't recognise that there is an extra argument before the body.
The only other thing is that the &body indentation doesn't work in the lisp buffers created by opening a file. But I suspect that is because I still have ilisp installed, and it is clobbering whatever slime does.
[...]
This indentation problem is most likely because lisp-mode isn't configured to use common-lisp indentation style. There's now an easy way to do this from ~/.emacs: (slime-setup). That configures lisp-mode-hook to enable slime-mode and to use common-lisp indentation. You can instead use (slime-setup :autodoc t) to also enable the autodoc mode.
Yes, this was it. Ironically, I commented out the line in my .emacs file that set the lisp-mode style to common-lisp when testing slime, thinking that it might interfere.
But anyway, I'm certainly a happy customer. Will ditch ilisp and see how things go.
Cheers,
Iain