Make using subrepls seamless

[TimoFreiberg]

This is written from the perspective of CIDER - I assume this still belongs here and not in CIDER

If you call (clojure.main/repl) in nREPL, the reading and printing is not done via nREPL magic anymore but by the implementation of clojure.main/repl.
The stdin reading triggers an outgoing nREPL message with status ("need-input"), which CIDER handles completely different than the normal input prompt in the REPL buffer.

This currently prevents using a break macro (https://gist.github.com/leobm/6061734) in CIDER
and causes clojure-emacs/cider#2017.

[bbatsov]

Would you be willing to tackle this? I'm afraid I'll be really short on time for the next month or two.

[bbatsov]

Btw, we are using clojure.main/repl internally (https://github.com/nrepl/nREPL/blob/e77945a70f68989f69e955eef9e6cbe75cedacf4/src/clojure/nrepl/middleware/interruptible_eval.clj#L87), so it seems we just have intercept such evaluation and handle them differently. I recall I saw some tickets or comments mentioning that @cemerick came to regret this decision eventually (to leverage clojure.main/repl), as it didn't turn out to be as flexible as needed, but this was a while ago and maybe things are looking better now.

I'm not very familiar with this part of the codebase.

[TimoFreiberg]

I would very much like to tackle this, but I definitely want to discuss any non-obvious design decisions with you/Chas/whoever is interested.
I'll think about the problem and start looking at the existing code.

[bbatsov]

Sure.

On Fri, 31 Aug 2018 at 17:42, Timo Freiberg ***@***.***> wrote: I would very much like to tackle this, but I definitely want to discuss any non-obvious design decisions with you/Chas/whoever is interested. I'll think about the problem and start looking at the existing code. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGVyqdD2YmFZyxNX-igQ-RTsq5SvMNpks5uWUttgaJpZM4WVKO8> .

-- Best Regards, Bozhidar Batsov http://www.batsov.com

[bbatsov]

I would very much like to tackle this, but I definitely want to discuss any non-obvious design decisions with you/Chas/whoever is interested.

I think the assumption with the current implementation was that the implementation would be simplified if it was built on top of the standard Clojure REPL, but I guess this also proved limiting in some ways. Generally as long as we have a solution that works well for Clojure and ClojureScript (piggieback) we should be good and ideally this solution should not be too coupled with Clojure's internals.

I also think that probably that particular problem will be easy to solve even with the current setup and maybe some small improvements to clojure.main/repl might be the best course of action long-term.

[bbatsov]

@cgrand If you have some time I'd appreciate to hear your insight on this ticket. I'm guess you're probably more familiar than me with Clojure's REPL implementation details.

[cgrand]

First the use main/repl by interruptible-eval is unrelated to the problem.
I'm indeed familiar with the issue of subrepls -- unrepl being a "subrepl".
The core of the issue is that repls don't compose: when one starts a repl inside a repl, the new repl takes full control of input and output streams. Did you set up something special in read/eval/print of the parent repl? It's gone, inaccessible while you are in the nested repl.

So having many repls that specialized on one single aspect isn't going to compose: you can't just nest them like russian dolls and expect to have the benefits of all of them, you usually end up with the benefit of the last one and a ton of interferences. That's a point which is often overlooked when talking about the power of "upgrading" a repl.

The only thing that persists from the parent repl is its dynamic bindings. Especially *in* and *out*.
If you have set up (in the parent) a special *out* that captures output so as to frame that in message then it's going to frame any output from the child repl... mixing together eval results, real output and prompts.

This is a problem shared by any repl whose output is framed in messages, be it unrepl, nrepl or even prepl: once in the repl you have a subpar experience because all the added value of the parent repl is gone.

So currently I think the only thing we can do is make the client gives better feedback on what's happening. From the time you get the "need-input" status to the "done" status, it should be conveyed to the user that we have left the usual repl experience and that anything can happen (it may be a REPL, or a game of Zork, a brainfuck toplevel... anything).

Last thing when we are able to understand a repl putsch is happening, the new repl has already written its prompt!

[bbatsov]

So currently I think the only thing we can do is make the client gives better feedback on what's happening. From the time you get the "need-input" status to the "done" status, it should be conveyed to the user that we have left the usual repl experience and that anything can happen (it may be a REPL, or a game of Zork, a brainfuck toplevel... anything).

I agree.

Another option - I wonder if we should intercept attempts to start a subrepl and just return some informational message saying that's not supported for the benefit of the user? I guess that'd be relatively easy to implement and would be better than the current experience.

[cgrand]

Not supported for the benefit of the user.

Is it that difficult for a client buffer to go in “dummy mode”? With a banner at the top and at then (if it ends). The top banner could explain that you can exit the subrepl by interrupting and that some features have been disabled. (Which ones by the way?)

[dkarvik]

That would depend on the client. Vim's client is very much "transient". It connects to an nrepl, evals, then disconnects.

[cgrand]

@SevereOverfl0w so this client doesn't handle :need-input for example? Or what happen if the evaluation takes a long time? Also I believe things have changed on the vim side since Vimpire seems to handle lasting connections well.

In any case, from a protocol point of view, if the protocol allows for degraded experience the client can still choose to not implement it. The converse is not true: if the protocol refuses degraded experience, there's nothing the client can do to support it.

[bbatsov]

Btw, there are currently two vim nREPL clients - the "classic" https://github.com/tpope/vim-fireplace (I believe @SevereOverfl0w if referring to it) and the "modern" https://github.com/liquidz/vim-iced. vim-iced makes use of the new functionality in vim8 and is an almost exact port of CIDER to vim - e.g. it has a REPL buffer, it has the stepping debugger and so on.

[cgrand]

I had this vague idea over the weekend: if clojure.main/repl (or something like that) was dynamic and subrepls author sticked to it to implement other repls then host repls could bind it to ease integration of subrepls.