Hi Erik, I've been switching from Clojure to Common Lisp myself, and have also found that there are some issues with ob-lisp.el (although I've been too busy recently to look closely at them).
ob-clojure.el works well, and uses slime for code evaluation -- and it has a simpler setup than ob-lisp -- so maybe it would be possible to port the code in ob-clojure over to common lisp? I'll be happy to help get ob-lisp.el into shape once I have a free moment... Cheers -- Eric Erik Iverson <er...@ccbr.umn.edu> writes: > Hello, > > I have started playing around with SLIME and was pleased to find there > was already some support in org-mode for evaluating Common LISP > blocks. The comments in ob-lisp.el makes it clear that it is not > complete support yet. It appears for example that you can only > evaluate one lisp form per code block. Here is an example. > > * First, let's try in emacs lisp > > The following works how I would expect. The value in the results block > is the value of the last expression in the code block. > > #+begin_src emacs-lisp > > (defvar test1 "test1 value") > (defvar test2 "test2 value") > test2 > > #+end_src > > #+results: > : test2 value > > * Now, let's try common lisp > > First, we need to start up a SLIME session, with M-x slime. This > assumes you have SLIME set up correctly. I am using SBCL as my CL > environment in this example. > > #+begin_src lisp :session > > (defvar test1 "test1 value") > (defvar test2 "test2 value") > test2 > > #+end_src > > #+results: > : TEST1 > > You see the result in the buffer is the value of the first form, and > if I go into the inferior-lisp buffer, test2 is not bound to any > value. If I evaluate the CL code block above without the :session > argument, I get an error in the *Org-Babel Error Output* buffer. > > Looking at the code in ob-lisp.el, I think I see why this is > happening, but don't know enough about SLIME yet to make it work. It > seems that line that calls =eval-slime= would need to be changed to > =eval-slime-buffer= after dumping the code block into a temporary > buffer. However, that didn't quite work since that function > (=slime-eval-buffer=) doesn't appear to actually return the final > value. > > So, I write this in case this is an easy fix for someone with more > knowledge of SLIME, and to confirm that this is indeed the current > behavior that others see. I will continue to investigate a solution. > > Thanks, > --Erik > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode