Luke Gorrie luke@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