Hi all, Let’s consider the plain repl (`lein run clojure.main -r`). What’s wrong with it as a repl meant to consumed by a UI richer than a term? non-readable and interleaved output, text-only (rendering images, tables, downloading big values etc.). The input of a repl is fine, the output is not. Things went bad as soon as we try to mess with input (all kind of discussions on escaping, buffering, concurrency etc.) You don’t kill a cat by sending a ^C to its stdin, you kill it by sending a ^C to the UI (the shell) that will use another channel (signals) to kill it.

So everything else including control of the repl should happen through another connection.

However since creating several connections is not always possible, one solution is to have a generic multiplexing layer.

We would have this kind of scenario: 1/ connect to repl 2/ send multiplex upgrade 3/ open a repl (through the multiplexed link) since the first one has been upgraded away 4/ upgrade it to unrepl 5/ open more repls and upgrade them to whatever endpoints you need (completion, sideloading, unrepl control etc.)

So basically there are now 3 decoupled concerns: unrepl, multiplex and discovering upgrading best-practices.

hey @cgrand

> However since creating several connections is not always possible, one solution is to have a generic multiplexing layer.

is that really something we should worry about for a tool driven REPL?

I mean in which scenario do you have a running REPL you can connect to with a tool but not launch another connection

this serves two purposes: 1/ removing the need to mix control & input from unrepl (use N connections!) 2/ if you are stuck with one connection, you can always use this shim

only thing I can think of is running something on a server in tmux

but how would tool get at that REPL?

as soon as you have a socket and connected to it once you should be able to connect more than once no?

being stuck with one connection is sometimes a limitation on the tool side (cough vim cough)

really? doh

a little bird told me it changed recently

seems that could be solved on the client side though by launching a helper tool instead of directly connecting

Even if it's because of a weird setup a helper tool can solve this.

The point is we can assume the client can create plain repls at will. How is out of scope.

Neovim makes it a doddle. Vim8 :thinking_face: Yeah, that should be good too. You can launch multiple jobs.

I'd think if a client can't open multiple connection, it's their problem to fix

I'm not sure I'd go that far.

I mean you could envisage some sort of multiplexing proxy to deal with this limitation

At any rate, the drawbacks of adding multiplexing (additional complexity) seem to weigh heavier than the potential reward (works with vim7?)

Vim7 works with nrepl & fireplace.

So you just do sync in Vim7 (like now)

Just to be sure my position is not misunderstood: assume multiple connections. In constrained environment use some kind of multiplexing.

I really like the recent simplification of the proposal by the way

The idea of using a separate connection to implement ^C is cool