[slime-devel] Re: swank:eval-string in wrong package?

Peter Seibel peter at javamonkey.com
Tue Mar 16 17:39:47 UTC 2004


Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> Peter Seibel <peter at 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.

That makes sense to me. Though it seems like it might be nice for
INTERACTIVE-EVAL to take an optional package name so one can send
this:

  "(:emacs-rex (swank::interactive-eval \"(foo bar baz)\" :some-package-name) nil t 477)"

And have the READ of "(foo bar baz)" happen in the package
SOME-PACKAGE-NAME instead of *BUFFER-PACKAGE* (or in cases where there
is no *BUFFER-PACKAGE*)

> If you need to READ in a particular package, you can use the same
> approach as we do for INTERACTIVE-EVAL.

You lost me there. It looks like it just uses *BUFFER-PACKAGE*.

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp





More information about the slime-devel mailing list