[slime-devel] Re: Evaluate forms from within Lisp buffers and displaying the result in the REPL

[Marco Baringer]

"Bill Clementson" <billclem at gmail.com> writes:

> Hi Rainer,
>
> On 4/17/07, Rainer Joswig <joswig at lisp.de> wrote:
>> I'm a bit used to the behavior of MCL when it comes
>> to Lisp buffers and listeners. Maybe SLIME developers
>> know how to achieve a similar behavior or would like
>> to provide something similar.
>>
>> MCL allowed multiple Lisp text editor windows and listener windows.
>> If there are multiple listeners one is the front most.
>
> SLIME does allow you to have multiple REPL windows. When you do "M-x
> slime" multiple times, it will ask you whether you want to create an
> additional repl.

are you sure? i tried this today and multiple M-x slime will start
multiple swank-servers in the lisp but you still only get one repl
buffer (this looks a lot like a bug).

>> SLIME displays several forms evaluated from a text buffer in the REPL like this:
>>
>> ;;;; (+ 1 2) ...
>> ;;;; (+ 1 2) ...
>> ;;;; (+ 1 2) ...
>>
>> The normal REPL interaction display would be like:
>>
>> CL-USER> (+ 1 2)
>> 3
>> CL-USER> (+ 1 2)
>> 3
>> CL-USER> (+ 1 2)
>> 3
>>
>> Both ways look different. Why not use the latter for both interactions?

this would only make sense, imho, if evaling code in the buffers
respected the repl's *package*, *readtable*, etc. and updated *, **,
***, +, ++, etc.

is this what you're suggesting? i'm not sure i like it, it's nice to
have some code in the repl which tests a function and have recompiling
that function not upset the state of the repl. however if we allowed
multiple, independant, repls this wouldn't be such a problem.

>> Useful is then also a command to rotate between the various listeners (next, previous)
>> and Lisp buffers (next, previous).
>>
>> Advantages I see for MCL:
>> * With MCL you get the same REPL listener display if you evaluate forms from
>> the Lisp editor buffer (via RETURN) or if you use the REPL in the listener.
>> * Using the enter key (vs. Return) to evaluate code in the editor gets
>>   rid of one complex keystroke.

what's the complex key stroke you want t get rid of?

>> * One gets reusable interaction histories in the listener where form and result
>>   are displayed together.

do you use this with normal functions as well or just snippets of test
code? if so how do you avoid being overwhelemed with slightly similar
but different function/class/whatever definitions interspersed with
'interesting' code and results?

>> Is SLIME already providing something similar? Would others find this way of interaction
>> between Lisp buffers and a REPL buffer useful?
>
> I don't think SLIME provides this as a standard feature. However, I
> have a function that I use to do this. It sends to the repl buffer
> either the current highlighted region, or the sexp that is on/before
> the point, or the sexp that is on/after the point, or the top-level
> sexp (if the point is not on/before/after a paren). With a prefix arg,
> it will also press "Enter" in the repl so you don't have to press
> enter yourself. I frequently use the function when I'm doing
> presentations and want to step through code in a listener for the
> audience.
>
> Here's the code with a sample binding of F9 (so use either F9 or C-u F9):

did bill's code do something similar to what you wanted?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen