Not sure what’s possible to add there. We are considering all sorts of things regarding this. I think the hottest candidate right now is a read only view.

please don't take this as "it should definitely be like this", but from a 'possibilities' perspective, the 'alive' extension does this with its CL repl:

That's great info, Bob! Thanks, I'll check out the project and learn a bit with them since it's exactly what I had in mind. I'll probably try and put something like this in place for calva in a local build. So I'll let the channel know if I'm successful. Would love to contribute this to the project, even tho I have a feeling it's way above my skill set right now

Awesome, @U05B6QEPMQD. Your comment about skill set reminds me of when I started with Calva: https://clojureverse.org/t/editor-connected-repl-for-beginners/1813/14?u=pez 😃

I'm half-joking but not really when I say this: if this goes in, I beg for the title of it to be something more specific than 'REPL' to avoid confusion for me (and potentially others) who end up using both extensions 🙂

Yeah, we should make it a bit more specific.

That's a really nice incentive for me to continue persuing this, thanks @U0ETXRFEW. I hope to able to help the project in the future.

Thanks for taking time to consider improvements to Calva, @U05B6QEPMQD. I wonder what the benefit of this is are over evaluations in-line in a file (such as within comment forms). The debug console just seems like a more limited version of the capabilities we already have in the editors, including in the output window where there's also a prompt. One downside is that I think it only allows for a single line of input. I'm also unsure how much control we can have over the display of the output.

+1 for this feature/idea, It's something I missed when trying Calva forthe first time, a way to not need a separated window for the repl. Also, from my POV would make Calva REPL close to Emacs's CIDER and vim's repl, which is good for newbies or people changing editors

@UKFSJSM38 how would it make it more similar to CIDER’s repl? I get curious because Calva’s REPL is designed with CIDER’s as a model.

As for a singe line of input… iiuc we can do whatever we want there. And JS debug console input is multiline, so the prior art also says we can make it multiline. (Not that we can reuse the built-in console, so maybe it is not a relevant datapoint, but anyway.)

> a way to not need a separated window for the repl. @UKFSJSM38 By this do you mean not needing a separate VS Code editor/file open in the VS Code window? There's still a need for a pane / some UI element. Also by "the repl", do you mean a place besides your code buffer/editor to enter code to evaluate, or do you mean a place to show evaluation output? Either way there's some element somewhere in your VS Code window to house those things. I don't follow what's different between CIDER and Calva on that higher level.

My point is more like when I'm coding, I have the buffers from my project files where I can freely open and close and the repl always in a fixed place like the bottom in the screenshot, where usually I just use to see output if I (println )something. When I was using Calva, I was missing that, so when I was coding and print or eval something that I'd like to see in the repl, I needed to change to the REPL Output panel or split it as a vertical window (maybe there is a way to have it together with the debug console, but I think it's the feature we are discussing?)

(I don't edit that repl buffer to eval things, it's just visual most of the time, to see printlns)

Thanks for the explanation. That makes sense. So the main point is having a fixed UI element (or being able to fix it), that shows output.

A long time ago Calva had output in an output channel (in that UI area @U05B6QEPMQD posted a screenshot of, but in the Output tab). The output channel had its own downsides though.

Also @U05B6QEPMQD I meant this as Eric's main point, not yours necessarily: > So the main point is having a fixed UI element (or being able to fix it), that shows output. I think you also want a fixed place for input, outside of code files, right?

Yes! @U9A1RLFNV that's manly it. And just to clarify, the plan is not to use the already existing panels like the debug console or the output. Is to create a totally new panel that we could customize for better fit the use case

I only used a screenshot of the debug console to show an example of the layout. Having the input fixed on the bottom.

yeah, I liked the fixed input too, looks like best of both worlds :)

Since I don't know much about developing a vscode extension, I'm not sure about the limitations of a panel, and the plan is to not lose any features calva currently have. I'm already studying this, but it'll probably take some time for me to put a proof of concept in place.

pez had mentioned a discussion - is there an open thread for this on github or anything (I don't see anything in a quick skim)? I had some alternate ideas to through into the mix, but I don't want to hijack this thread off in a different direction

I guess I shouldn't say 'discussion', but rather the mention of considering several ideas

Please reach out often to share your thoughts, design ideas, and implementation ideas. I want to make sure we're all on the same page before you spend much time implementing. @U0ETXRFEW and I have been considering making the output UI read-only, but that can be separate from this pane you're talking about, maybe? If we can also have some way to make the new output element we come up with (whatever is used) fixed, I think that would be ideal. I'm not sure yet what all of our options are. What I think we do want to avoid if we do provide a way to input code besides code editors is any kind of complex code around input. And I think the extra input area should be separate from the output. The current output implementation is complected with the ability to input code for not really much benefit. Also when we used a webview that was read+write it had its own sophisticated input system like its own paredit, and it was a maintenance burden.

@U013JFLRFS8 We should start a discussion on this on GH. Give me a minute.

https://github.com/BetterThanTomorrow/calva/discussions/2238 Please provide any feedback on a new output experience here.

Well, CIDER’s repl is not at a fixed place, afaiu. It can be moved around. I see the fact that a debug panel solution can’t be moved around as a huge drawback. I move the output window around a lot during my sessions. Most often I run with the panel hidden and the output window at the bottom, below the file I am working with, with the jack-in terminal side by side. None of that can be achieved with the debug panel.

What does fixed input mean, @U05B6QEPMQD?

Thanks for creating the discussion, I'll try and contribute there as well. @U0ETXRFEW I probably didn't express myself very well with this one. This just means that the input area ins't dependent of the history of outputs. Here's one example with terminals. The first one, the input always goes after the history of output. The second one, the input area is fixed on the bottom. Not a major thing, of course. Just something that would be possible and I personally, think is better.

Here’s an example for how it can be arranged today, @UKFSJSM38

Thanks, @U05B6QEPMQD. That’s what I thought you meant.

That's interesting @U0ETXRFEW, looks quite similar to what I was seeking

> Well, CIDER’s repl is not at a fixed place, afaiu. It can be moved around. I see the fact that a debug panel solution can’t be moved around as a huge drawback. My thinking of "fixed" is really that it's independent of the editors you might be opening and closing as you work on a project - that it can stay in one area of the screen and no editor will ever open on top of it / in the same area of the VS code window. Currently if you select the output window for some reason, then you open some file, it'll open in the same area as the output editor and essentially hide the output editor. That's not a huge deal to me though ^ - I just wanted to provide some clarification on what I and maybe someone else might consider "fixed". Also, using an editor as we do allows for flexibility as you show above, @U0ETXRFEW.

Though, maybe the same flexibility for positioning is also provided with the pane where the output channels, etc. live. I'm not sure.

@U0ETXRFEW do you have an incantation for tweaking where the output window shows by default? I was just typing that as a suggestion on the discussion, but now wondering if there's some calva-fu I'm just missing... i.e. if you close the output editor in the bottom left and then show it again, does it open in a new right-hand split, or back where it was (not that vscode necessarily knows it the same thing being re-opened)?

> Though, maybe the same flexibility for positioning is also provided with the pane where the output channels, etc. live. I’m not sure. Nope. Only the terminals can be freely moved around. The other panel stuff can only be moved around in the panel, or over to the side panels. VS Code is super stupid with this. I’ve suggested it should be more flexible, but they are not planning to: https://github.com/microsoft/vscode/issues/68831

@U013JFLRFS8, the API does not allow for much. It only allows for choosing columns, which we do today, so it will open in the same column as you last closed it from.

What could be the case, however, is that we can use much of the same webview code for a regular webview (which is treated as an editor by VS Code) and for panel webviews. And then the user can have a setting for using a panel or an editor webview. And if we separate input and output in different views, the user can arrange those more freely as well.

I think that would be awesome

@U05B6QEPMQD, please give that debug console-ish view a shot if you find the time. It needn’t be anything close to perfect to be valuable for use and get a feel for how it would be like.

A somewhat working prototype can probably be done with #C03DPCLCV9N, but it’s not necessarily easier to do it that way.

Of course, I'll do that, even if nothing comes out of it, I at least will be more familiar with the project and would be able to help with other things in the future.