Peter Seibel peter@javamonkey.com writes:
You are right. The docstring isn't quite correct. We could probably remove one level of printing/reading by passing a form instead of the string. We could then rename the function to EVAL-FOR-EMACS.
Hmmm. I'm not sure that's a good idea--I was looking at this because I specifically needed to evaluate a form containing symbols I grabbed from my emacs buffer. But I need those to be read by CL in the proper package. Given the emacs s-exps and CL s-exps are *not* exactly the same it seems better to let the communication between emacs and CL be via strings. Or maybe I misunderstand you.
Perhaps the issue becomes clearer with some examples. Evaluating (+ 1 2) with C-x C-e proceeds as follows:
1. Emacs sends the string "(:emacs-rex "(swank:interactive-eval \"(+ 1 2)\")" nil t 477)" with a 3 byte header indicating the length to Lisp.
2. Lisp reads the 3 bytes, allocates a string and copies the string from the socket into the string.
3. Lisp READs from the string in the swank-io-package and gets the form: (:emacs-rex "(swank:interactive-eval "(+ 1 2)")" nil t 477)
4. DISPATCH-EVENT (or READ-FROM-SOCKET-IO depending on the communcation style) calls EVAL-STRING with "(swank:interactive-eval "(+ 1 2)")"
5. EVAL-STRING READs the string in the swank-io-package and calls EVAL with: (swank:interactive-eval "(+ 1 2)")
6. INTERACTIVE-EVAL reads the "(+ 1 2)" in the *buffer-package* and sends the result back to Emacs.
I think we can get rid of the READ in 5. by sending "(:emacs-rex (swank:interactive-eval "(+ 1 2)") nil t 477)" in 1. The :emacs-rex message is created by the slime-rex macro, and the argument there is conceptually a form (where all symbols are fully qualified) and not a string. So I think we wouldn't lose any flexibility.
If you need to READ in a particular package, you can use the same approach as we do for INTERACTIVE-EVAL.
Helmut.