@screwlisp
I only have the idea right now, and it is something very vaguely inspired by the traceback buffers in Slime/Sly that would be hard to summarize in a few sentences... my plan was to ask you how you would translate this to two SBCLs running in parallel, with Slime controlling both - just forget the 3-window setting and use a 2-window setting, it would be easier for you - and then I'll start by your translation and build the interface the selects the right Slime target...

• (find-3EE '(eepitch-shell) '(eepitch-shell2))
• (find-3ee '(eepitch-shell) '(eepitch-shell2))
• (eepitch-shell)
date > /tmp/o

• (eepitch-shell2)
cat /tmp/o

@eduardoochs
generating ee find functions for the different repls? For my high level example I have written just now, I have one slime repl in charge of redrawing a gnuplot, and I have a second slime repl in charge of making the data for the gnuplot.

Debugging my example, whatever I typed didn't seem to get sending redraw to the gnuplot to redraw yet though so I will still be a few minutes.

@eduardoochs
Oh right I looked at your picture, something like using named pipes? As you saw in my gif, I gravitated towards emacs server-start and then using an emacsclient process to evaluate in emacs, possibly evaluating eepitch-send.

I forget exactly what, but asyncronously starting an external process inside common lisp slime was necessary to avoid what were tricky hook issues I think.

I really want the eepitch buffer I just pitched to to be able to use eepitch itself on another buffer.

@eduardoochs I didn't quite get to it but in my example today, you can see I have a three buffer configuration, where my control buffer is alternating commands between an SBCL image to numerically compute values, and an ECL image running a graphical app.

1. I pitch to sbcl, performs the first step
2. Then I pitch to ecl, performs the second step

Instead I want to watch:
1. I pitch to sbcl, performs the first step
2. sbcl asyncronously pitches to ecl to begin the next step.

@eduardoochs here's a working #commonLisp multislime #eev #eepitch, going via emacsclient --eval and #emacs server.

It's (partially) async and works for slime1 ! slime2 ! slime1 and so forth I think.

https://screwlisp.small-web.org/eev/emacsclient-eepitch-the-reckoning/

But it does require M-x server-start. And it's a common lisp object system class (port to emacs lisp? ;p) I dunno. What do you think?

@eduardoochs I really like your temporary file/directory, git stuff, the thing with the customized code-c-d with regex, though well-integrating it and also sharing with others are two big challenges.

I appreciate how much effort you put into conveying how easy eev is to use.

http://anggtwu.net/eev-intros/find-eev-install-intro.html#5.1

@screwlisp The first prototype of an eepitch-sbcl-slime is ready! Now if we run this in a buffer - the "source buffer",

• (eepitch-sbcl-slime)
• (eepitch-kill)
• (eepitch-sbcl-slime)

then each (eepitch-sbcl-slime) creates a temporary buffer like the one in the screenshot... usually we would just type a series of <f8>s to check that the current target to eepitch is a slime/sbcl buffer and to go back to the source buffer, but in the cases in which we need to create a new slime/sbcl target we need to type a mix of <f8>s and <down>s - to execute some lines and skip some other ones - and then at some point slime will run and we need to type M-x b at the slime/sbcl repl... the M-x b does all the rest, that I will explain later, after playing with this a lot and rewriting parts of it a few times... =S