New and Improved Output Experience

[bpringe]

@PEZ and I have been considering a new and improved output experience that will be read-only. The read-only requirement allows us to do more with less, to put it simply.

Calva's current output window allows for input, which makes the code more complex and makes it harder to provide a better output experience (like fast-streaming output, and a being able to handle a large amount of output in the output area without the output experience getting laggy/slow).

Using a read-only UI element, perhaps a webview, or some other element, should allow us to achieve a much smoother and better output experience.

Having a prompt in the output window also, IMO at least, encourages Clojure beginners to type code into the output window rather than evaluating code directly from their code editor/file, which can really delay a deeper understanding of the power of REPL-integrated Clojure editing environments.

We can use this thread to discuss ways to provide a better output experience.

[bpringe]

Past output implementations:

• Read+write webview: This became a huge maintenance burden because the webview had its own paredit for input, and the output (I believe) had its own implementation details separate from how editors handle output (like for formatting and highlighting).
• Output channel: This had some downsides. Downsides I can think of for using an output channel today:
  • Last I checked, there was a wrapping issue with the output channel - some undesirable wrapping behavior of which I don't remember the full details.
  • While an output channel provides scroll locking out of the box, the scroll locking becomes disabled if you click in the pane, such as to copy some result, at which point the user has to re-enable the scroll locking themselves, such as by clicking the lock icon in the output pane.

[PEZ]

We've also had terminals as repls. So when things where evaluated there, the output was printed there as well. I think we printed file evaluations in output channels back then.

[bpringe]

It might be a good idea to use a decision matrix for potential solutions, one like Rich Hickey describes in Design in Practice.

[ericdallo]

My feedback as an Emacs CIDER user

It's true that cider's REPL is really customizable, and it's handled as a buffer, so you can move it, close, re-open and all sorts of things you can do like a file, but from my experience using and seeing other people at Nubank user is that most of the time, if not all the time, we use it as a fixed window at bottom (or right for few people), but we do not use it to edit, but to see output or exceptions, this way we don't need to switch to a REPL buffer somewhere and mess the files opened in the editor.
So a fixed window at the bottom would already be a big improvement to me, the fixed input is a nice to have that I found interesting.

[PEZ]

A fixed output as the only option would totally break my workflow. But, sure, I often arrange my editors like that as well:

[PEZ]

VS Code is pretty stupid about how things can be arranged. But terminals can be moved into the editors area, allowing for the above layout, as well as something like so:

[PEZ]

I lean toward separating output and input. And having several options for output. Including options for splitting stdout from results.

Not fond of Calva being opinionated about not using the prompt for evaluations.

Relevant issues:

• Add some output options #1104
• REPL is Slow and Performance Degrades as the Output Grows #942
• Add support for the Portal Extension #1327
• REPL on vscode built-in debug console #1669

[bpringe]

I lean toward separating output and input. And having several options for output. Including options for splitting stdout from results.

This sounds good to me. It might be a good idea to start with one option for output and then add others after the first option is released.

Not fond of Calva being opinionated about not using the prompt for evaluations.

If by this you mean you want to provide some way to send input to the repl that's not directly from a code file/editor, then I think I'm fine with that as long as that input mechanism is not part of any output mechanism, or at least as long as it does not limit the usage or capabilities of the output window, and is not coupled with any output implementation. I think we agree here, though, judging by what you said about separating output and input.

I don't see myself using that input feature, but if it would be a simple implementation and thing to maintain and more than a small percentage of Calva users would use it, then I guess I don't see a problem with it, aside from maybe this:

Having a prompt in the output window also, IMO at least, encourages Clojure beginners to type code into the output window rather than evaluating code directly from their code editor/file, which can really delay a deeper understanding of the power of REPL-integrated Clojure editing environments.

[gerdint]

Though I am a long-time Emacs user I have done most of my Clojure hacking in Cursive. I very much like separation of input and output windows there. It feels more robust and I have never missed any features of a full-blown Emacs comint-mode buffer.

I think the necessay features in input pane amounts to basic line editing (Paredit would be extremely handy) and being able to cycle between previous input history.