Is there a convenient function for running bits of CL code (in the backend common lisp of course) from elisp?
I've been playing around with slime-eval-with-transcript and slime-eval-async, with rather mixed success. Most commonly, I just get a protocol error and lose my slime connection.
Am I looking in the wrong place, perhaps?
Why do I want this? Say I am editing some (non-lisp) file and then want to process it by feeding the filename to some function in the CL backend. I'd like to be able to just run something like (slime-eval-thing `(process-file ,(buffer-file-name)) ":cl-user") and have the backend lisp run (process-file "/foo/bar") or whatever.
And, while we're at it, how about the backend lisp asking emacs to run some elisp code? Most importantly, I want to be able to have the backend ask emacs to open a file, and perhaps move to a specified point in the file. I notice that the debugger seems able to do this, so surely, the functionality exist. But how accessible is it to the user?
- Harald
* Harald Hanche-Olsen [2006-02-13 16:13+0100] writes:
Is there a convenient function for running bits of CL code (in the backend common lisp of course) from elisp?
I've been playing around with slime-eval-with-transcript and slime-eval-async, with rather mixed success. Most commonly, I just get a protocol error and lose my slime connection.
Am I looking in the wrong place, perhaps?
slime-eval-async is the recommended interface. E.g.
(slime-eval-async `(cl:lisp-implementation-type) (lambda (x) (message "%S" x)))
Note that slime-eval-async is intended to write SLIME commands and is a bit picky what you put in the expression. In particular you have to package qualify all symbols (including CL symbols except nil and t). If you forget the package, it's considered a read error and the connection is terminated. By convention, the expression should look like (SWANK:FUNCTION-NAME LITERAL ...) i.e. the arguments should only be constants, but the convention isn't enforced (yet).
slime-eval is pretty much the same but waits for the result. slime-rex is the low level interface for those few cases when you need some special Emacs side error handling.
[Btw, those functions take a package argument which is only useful for a few commands and I think it would be "cleaner" to include the package in the SEXP instead.]
And, while we're at it, how about the backend lisp asking emacs to run some elisp code? Most importantly, I want to be able to have the backend ask emacs to open a file, and perhaps move to a specified point in the file. I notice that the debugger seems able to do this, so surely, the functionality exist. But how accessible is it to the user?
swank::eval-in-emacs does that, but we use it rarely and the whole Lisp->Emacs communication isn't very mature. E.g.
(swank::eval-in-emacs '(emacs-version))
Don't forget to set slime-enable-evaluate-in-emacs before you try it.
Helmut.
+ Helmut Eller heller@common-lisp.net:
| (slime-eval-async `(cl:lisp-implementation-type) | (lambda (x) (message "%S" x))) | | Note that slime-eval-async is intended to write SLIME commands and is | a bit picky what you put in the expression.
Indeed, but I can live with that. It's just a question of packing it up into an elisp function that enforces the constraints.
| > And, while we're at it, how about the backend lisp asking emacs to run | > some elisp code? | | swank::eval-in-emacs does that, but we use it rarely and the whole | Lisp->Emacs communication isn't very mature. E.g. | | (swank::eval-in-emacs '(emacs-version))
That works, but (swank::eval-in-emacs '(find-file "/tmp/foo")) killed the slime connection. (But it did run open a buffer on /tmp/foo first.) It also produced quite a lot of information in the *inferior-lisp* buffer. I have saved it in a file, so if anybody would like to see it, drop me a note. But I bet y'all can reproduce this yourselves.
Wait, I think I see what is happening: The find-file returns the value #<buffer foo>, which is probably too hard to handle. But this works fine:
(swank::eval-in-emacs '(progn (find-file "/tmp/foo") t))
Thanks for the help.
- Harald
-
Harald Hanche-Olsen -
Helmut Eller