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

[Rainer Joswig]

In article 
<8757cb490704230700l1a58b46em4ba1ade36851c6e1 at mail.gmail.com>,
 "Bill Clementson" <billclem at gmail.com> wrote:

> On 4/23/07, Rainer Joswig <joswig at lisp.de> wrote:
> > In article
> > <8757cb490704222232m429a62avf02c9225cb2c68fa at mail.gmail.com>,
> >  "Bill Clementson" <billclem at gmail.com> wrote:
> >
> > > Hi Marco,
> > >
> > > On 4/20/07, Marco Baringer <mb at bese.it> wrote:
> > > > "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).
> > >
> > > Yes, I'm sure. Well, at least I'm sure it does one specific thing
> > > (which may not be what you think Rainer wants nor what he actually
> > > does want ;-) ). I don't usually use multiple repl's, so I'm not sure
> > > I understand the specific use case that Rainer wants to address. As I
> > > see it, there may be 3 different types of "new" repl's that one could
> > > want to have (which, depending on your specific use case may or may
> > > not be what is required):
> >
> > The basic interaction between an Lisp editor and a Lisp listener
> > is a bit different in MCL. I found it a bit more convenient
> > then what SLIME currently does. In the simple form it
> > is mostly independent from the multiple buffer issue.
> > In my other posting I had explained the MCL interaction
> > a bit more.
> 
> Yes, but you never really indicated WHY you wanted to use multiple
> repls. You said that you used them all the time in MCL, but didn't
> indicate the types of use cases where multiple repls would be of
> benefit. Of the 3 scenarios I describe below, which one(s) matches
> your use case for multiple repls?


The multiple REPLs are usually connected to one Lisp.
The REPLs:
* could be in different packages, could have different I/O settings, ...
* could execute different long-running tasks (like rendering a bunch of HTML to a file from some data)
* one REPL could be for debugging, the other for a long running execution or to create output.
* sometimes you create a version of REPL which does run another embedded language
  (Scheme, ....) from the same Lisp.


> 
> > > #1: You want to "play around" with some ideas but don't want to "muck
> > > up" your existing lisp environment and repl. In that case, you
> > > probably want to start up a new lisp instance and test things in a
> > > completely independent repl. When I do "M-x slime" multiple times (and
> > > say "n" to the "Create an additional *inferior-lisp*?" prompt), that
> > > is exactly what I get - multiple lisp instances with a separate repl
> > > for each one. I can use "C-c C-x c" to switch between them so I can do
> > > my "mucking around" in the one repl and do the "real stuff" in the
> > > other repl ("C-c C-x c" also controls which repl is "active" when
> > > you're in a lisp buffer compiling/evaluating/etc code).
> > >
> > > #2: You want to have multiple repl's on the same lisp instance (with
> > > each repl sharing the repl history and */**/***/etc values). This is
> > > useful if you want to use one repl for a demo but want to be able to
> > > enter other commands in another repl to set up or modify an
> > > environment for the demo. There are probably other use cases for this;
> > > however, this is what I normally use #2 for. Again (as with #1), I can
> > > use "C-c C-x c" to switch between the repl's so I have control over
> > > which one is "active". Although SLIME does not provide any standard
> > > function for automatically creating multiple repl's, it is easy enough
> > > to do if you are using a lisp with threads. In your existing SLIME
> > > repl, you can just enter "(swank::create-server :port some-port)" and
> > > then in emacs do a "M-x slime-connect" and specify the host & port. If
> > > you do this a lot, you could automate it with something like the
> > > following:
> > >
> > > (defun slime-new-repl ()
> > >   "Create additional REPL for the current Lisp connection."
> > >   (interactive)
> > >   (if (slime-current-connection)
> > >       (let ((port (slime-connection-port (slime-connection))))
> > >       (slime-eval `(swank::create-server :port ,port))
> > >       (slime-connect slime-lisp-host port))
> > >       (error "Not connected")))
> > >
> > > and just do "M-x slime-new-repl" whenever you wanted a new repl. As
> > > you can see from the above function, although you can specify any
> > > port, you can also just reuse the existing port for the separate repl,
> > > so it's easy enough to do when you're ssh'ing to a remote machine too.
> > >
> > > #3: You want to have multiple repl's on the same lisp instance (with
> > > each repl having it's own repl history and */**/***/etc values). I
> > > thought that it was possible to do this at one time with SLIME;
> > > however, I just had a play and I don't think there is any way that you
> > > can currently do this in SLIME.
> > >
> > > I thought Rainer was after #1 when I initially replied. If he is after
> > > #1 or #2, SLIME currently supports these types of multiple repl's. If
> > > he was looking for #3, I don't think that is currently supported.
> > > Maybe Rainer could indicate what specific use case he is trying to
> > > address with multiple repl's.
> >
> > The basic use case (one Lisp editor buffer and one listener
> > buffer) would be:
> 
> The following applies for one Lisp editor buffer and one listener, but
> what is the use case with one Lisp editor buffer and multiple
> listeners?


That's not used that much. Mostly it is many Editor buffers and one or two listeners.

I use one Editor and two listeners sometimes.
All the forms I define, the data and the test forms are in the editor buffer.
One listener is for debugging (using break loops) and execution of code.
The other one is for testing out forms and redefining forms.
Both get their input from the one editor buffer.

> 
> > Write and execute the code from the editor. The code
> > will be read from the editor using the package
> > of the editor (or *package* if there is none).
> > The execution takes place in the
> > context of the listener. The result is printed
> > in the listener. At the end of the
> > execution the listener prompt is updated (position
> > at the end of the buffer) and the *,**,***,... variables
> > are set/updated.
> >
> > The streams of the listener will be used. Also the
> > printer settings of the listener will be used
> > for printing the result.
> >
> > The forms for execution should be entered in a queue
> > and executed one after the other. Pressing
> > C-x C-e (Enter) would execute the first form. If this
> > form is finished, then the second form will be executed.
> > By default a listener has only one execution going
> > on at any one time.
> 
> In MCL, what happens if there are multiple forms in the execution
> queue and one form results in an error? Are the remaining forms still
> executed?


Unless there is some other error handling going on, you get a break loop
in the listener.
After successful continuing from the error and successful execution
of the first form the next form gets taken from the queue and executed.

> 
> > I want C-x C-e to do something different and have it on Enter. ;-)
> > I never use the minibuffer for displaying Lisp results.
> > I'd better leave the minibuffer for command interaction
> > and display of messages.
> >
> >
> > SLIME (C-x C-e) currently:
> >
> > SLIME does not print the result of C-x C-e in the
> > Listener. The result is printed in the mini-buffer.
> >
> > SLIME does not set *,**,*** and related.
> >
> > SLIME does interfer with its listener prompt in interactions
> > in the listener. If a program prints to the listener
> > or reads from it, the prompt is always moved to the end
> > while doing output.
> >
> > SLIME (+ OpenMCL) happily executes two forms from
> > the editor via C-x C-e. But it starts the execution
> > of the second form immediately.
> 
> Have you tried out the slime-send-dwim function that I sent you in my
> previous email yet? It does do everything you describe above with the
> exception of queueing execution of multiple forms.


Yes, I have tried it. Thanks!

A few glitches:

* If I send a defun, after executing it, the cursor is not moved to the new prompt at the end of the listener buffer.
* if the cursor is on the end of a line behind a form and there is a form on the next line, the next form will be taken.
* after execution the cursor in the listener is not moved to the prompt.
* it does not take into account that the Lisp editor buffer package could be different from the Listener.

As I have mentioned earlier, I think the interaction between an Editor and a Listener is one issue.
The other one is this interaction in the presence of multiple Lisp editor buffers or listeners.
I understand that a full MCL-like interaction might not be possible or even
not desirable in Emacs, but I think the basic Editor/Listener user experience of
Slime could benefit from some other ideas.

Regards,

Rainer Joswig


> 
> --
> Bill Clementson

-- 
http://lispm.dyndns.org