[slime-devel] Re: What should `M-x slime' do?

[Peter Seibel]

Luke Gorrie <luke at bluetail.com> writes:

> Ahoyhoy,
>
> A few times I've sat down to "fix" the behaviour of `M-x slime' and
> `M-x slime-connect' as regards multiple connections but I always give
> up and can't decide what they should do.
>
> Here are some cases:
>
>   M-x slime, no prefix argument, already connected:
>     Close all connections, but don't kill any inferior-lisps.
>     If *inferior-lisp* exists then connect to that Lisp, otherwise
>     start a new one and connect.

Something to keep in mind (and which further complicates things) is
that there may be multiple Lisps involved. I.e. an Allegro and and
SBCL and a CMUCL and a CLISP.

Maybe we should look at this from the point of view of what the user
might actually be trying to do and then figure out how to map those
user-level actions onto commands and prefix-arg-command combos.

Speaking for myself the two things I ever need to do are:

 1) Start an instance of my default Lisp implementation and connect a
    SLIME REPL to it.

 2) Start an instance of another Lisp I use occasionally and connect a
    SLIME REPL to it. I actually rarely want this to become my default
    SLIME connection which is what happens now.

Now that you mention it I can also see the utility of:

 3) Start a new SLIME REPL connecting to an already running Lisp.

There are three subcases of this:

   3a) Connect to a Lisp that I started from within emacs.

   3b) Connect to a remote Lisp (one not started by emacs) but which
   SLIME already knows about (perhaps because I've already connected
   to it.)

   3c) Connect to a remote Lisp that SLIME doesn't know about yet.

Obviously in cases 3a and 3b there may be multiple Lisps that SLIME
knows about so I'll need to indicate somehow which one I want.

Of course if we have a way to start new REPLs we should have a way to:

 4) Close an existing SLIME REPL.

Related to all of this is the question of actually quitting the
underlying Lisp. Presumably some folks who use SLIME to connect to a
remote Lisp will want to be able to disconnect the last (or only)
SLIME REPL without killing the Lisp and perhaps reconnect to it later.

>   .. or with prefix arg:
>     Ask if we should create an additional connection.
>     If yes, create a new *inferior-lisp* and connect.
>     If no, do as above.
>
>   M-x slime-connect, no prefix argument, already connected:
>     Close all existing connections and then make the new one.
>
>   .. or with prefix arg:
>     Ask if we should close existing connections first.
>     If yes, do as above.
>     If no, keep existing connections and create a new one.
>
> Now that the protocol is robust I don't think you'd want `M-x slime'
> to reconnect to the current *inferior-lisp*, so maybe it should
> create an additional connection? And what about slime-connect?

So I'd be quite happy if M-x slime always started a new Lisp and
created a REPL to it. Ideally instead of setting inferior-lisp-program
to a single value, there would be a slime variable that contains a
list of lisps that can be run locally. The first item of that list
would be the primary lisp, the value currentlystored in
inferior-lisp-program. Then perhaps M-x slime runs a new instance of
the primary lisp while C-u M-x slime prompts for which lisp to run
with the list of known lisps automatically in the command history.
That covers my cases 1 and 2 nicely.

Then all the variants of 3 can be covered by M-x slime-connect. It can
prompt you for which lisp to connect to giving you a choice of making
a new REPL connected to any of the Lisps that SLIME knows about or to
a new lisp whose network address you must then supply.

The list of lisps SLIME "knows about" may be any Lisp that it has
connected to (either via M-x slime or M-x slime-connect) at any time
in this emacs session; any Lisp it is currently connected to; or
something else. If it's the first one then there should also be a way
to make SLIME forget about a particular Lisp.

> There's also the question of how we should recycle REPL buffers. I
> don't know if anyone has strong opinions on that.

What state is attached to a REPL buffer? The command history? Anything
else?

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

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