Allow language extensions to expose a persistent interactive console (REPL)

[daviwil]

While it is awesome that we have the Debug Console for an interactive console experience while debugging, it would be ideal if VS Code also supported a persistent REPL (interactive console) which could also be used at any time. Users of languages such as PowerShell, F#, Python, Ruby, and many others would benefit from this.

At least in the case of PowerShell, all that would really be needed is an event that can be registered when the user enters a command and then some API for writing the output. The PowerShell, F#, and Elm extensions already simulate this by allowing the user to select some text, run a command to execute it, and then have the output written to an output channel.

Users of the PowerShell extension have requested feature this here: PowerShell/vscode-powershell#10

cc @Krzysztof-Cieslak

[Krzysztof-Cieslak]

General 👍 to feature. Would be really cool to get such feature (especially when Debugging Console practically implements everything we would need)

For sure it would be useful for many languages (nowadays even C# has REPL ;) ). As David said, in F# and Elm we just allows user to send line / selection / file to REPL and we print output to Output Channel - that's how it looks more or less:

While for F# it's my decision to have such style REPL (we've implemented exactly same functionality [read-only REPL window] in Atom even though we could get more traditional style) other languages and their communities prefers to use REPL by just typing code into it and plugins supporting those languages would really benefit from adding this.

[Krzysztof-Cieslak]

cc: @mat-mcloughlin for Elixir plugin.

[mat-mcloughlin]

+1 on this feature

[RobCannon]

+1 on this feature. Also, I would like to see an option to see the REPL window on the bottom.

[egamma]

I would like to see an option to see the REPL window on the bottom

agreed and this is on our backlog.

[wjdavis5]

+1 want to run some npm, or nuget or stuff directly from vs code.

[daviwil]

Since 1.0 is on the way, I'd love to see this get added once you guys are prepared to start adding new features again. Users of the PowerShell extension tell me regularly that they would switch away from the PowerShell ISE completely over to VS Code if there was a persistent REPL experience.

Since Andre self-assigned this issue and removed the help wanted tag, I'll take that as a hint that work might be happening in this area soon :)

[weinand]

@daviwil @Krzysztof-Cieslak @mat-mcloughlin
In VS Code a debug adapter is only launched when a debug session is started. And the debug adapter is stopped when the session ends. At any point in time only a single debug adapter is connected to the debug console and can use it as a REPL.

• How should this work if the REPL could be used at any time?
• Is the debug adapter running all the time? So a 'terminate' does not kill the adapter but only kills the session?
• When is the debug adapter started? 'Launch' is probably too late because the REPL should work at any time.
• Is this a new lifecycle option of a debug adapter (contributed in the package.json)? With this option set VS Code would start the debugger early and not kill the adapter at the end of the session but reuse it as long as possible?
• What happens if I'm using more than one debug adapter with this behaviour? Will only a new session of a different adapter terminate the previous adapter?

Please provide input/insights/ideas in how we could improve the current architecture to support your use cases. Thanks!

/cc @isidorn

[daviwil]

That's an interesting idea, actually. If the debug adapter contribution could opt in to being launched when the extension gets activated and then persist across multiple debug sessions, that would work for my needs. Here are some general thoughts:

• If the debug console is now active at all times even if the debugger isn't running, could you make the debug console control also available in the editing workspace? I think it'd be limiting if the user could only see the console if they switch to the debug workspace.
• Do you think it might be time to consider allowing multiple debug adapters to be connected to VS Code at the same time? What if I'm a web application developer and I want to attach to both a client (JavaScript/Node) and server application (C#) and debug the requests as they travel between the two processes? To simplify the UI you could just allow the user to select the "active" process (at any time) so that only the details of that single process (breakpoints, variables, call stack, debug console) are shown in the UI. This would allow a persistent PowerShell debug adapter to be connected even if the user is also debugging some other type of application.

I've got a few more requirements to make this experience smooth for PowerShell but I'll send those separately in an e-mail because they require discussion that would just be extra noise on this issue.

[weinand]

@daviwil multiple debug sessions are already possible: just open another VS Code window on a sub- or super folder. I'm using this setup all the time to debug my (client) tests and the debug adapter (server) at the same time. We are planning to lift this limitation (a single 'if' statement) soon. Then it will be possible to open multiple windows on the same (project) folder.

[daviwil]

Cool! If you can open the same folder in two separate windows then that could simplify the multiple debug adapter situation.

[tiagodalloca]

+1 on this feature (REPL, interactive console)

[Krzysztof-Cieslak]

I wonder if this could be somehow connected with #143 - with terminal support we basically get "output" window where we can type stuff in... which is basically what we need for REPL.

On the other hand we can just start REPL from terminal and additional extension point for this is not required any more.

[daviwil]

The other possibility in 1.2.0 is to use the new vscode.startDebug API so that you can allow the user to use the Debug Console. It'd require your debug adapter to be able to run without a specific file, basically just dropping them into a prompt.

However, I'd much prefer to use the Terminal UI if I could provide the output for it. I'm not really a fan of having a separate input box :)

[Tyriar]

So is the idea here to basically be able to launch a powershell instance from an extension (or python, ruby, etc.)? #143 pretty much covers this entirely doesn't it?

@daviwil what do you mean exactly by "if I could provide the output for it"?

[weinand]

@Tyriar I think the powershell (or python, ruby, etc) instance runs in debug mode and interacts with the VS Code debugger UI. This applies to the REPL as well, so it should be possible to use the debugger UI to inspect the objects returned from the REPL eval.

[daviwil]

At least in the case of the PowerShell extension, I am hosting a PowerShell session in my language server (not as a separate instance of powershell.exe). This allows the user to write and evaluate PowerShell code and then have their session be affected by what's executed (new commands show up in IntelliSense results, etc).

In the case of the terminal control, it means that VS Code wouldn't be performing console emulation for powershell.exe. Instead you'd be sending my extension the text that the user enters and then allowing me to write output back to the terminal. If you check out the PowerShell ISE editor that ships with Windows (powershell_ise.exe), you'll see what I'm trying to achieve.

Andre's right, currently we expose a PowerShell console via the VS Code debugger and that works pretty well. The dream setup would be using the Terminal UI with my debug adapter backend since that would provide the exact experience PowerShell users expect.

[davidanthoff]

I'm investigating this for the julia extension.

I generally see two possible implementations right now:

1. something that uses the terminal support from Request feature "Integrated terminal" #143 and Support multiple integrated terminals #6458, and has no debugger integration.
2. something fancier that is integrated with the debugger.

For 1), all I would need is some API that I can use from my extension that opens up a new terminal window in the #6458 UI. The API should allow me to just pass in a command line that should start for that terminal (i.e. that command line would come from my extension call, not from some global terminal configuration). Ideally the API would also allow me to somehow "track" that specific terminal, i.e. it would be great if my extension would get events when the terminal is closed/hidden/terminates etc. @Tyriar is some of that maybe even already possible in insider builds? My extension would then add commands like "julia: open REPL", "julia: send current selection to REPL", "julia: send current file content to REPL".

Sending individual code to this julia instance would actually not work via just pasting that code into the REPL. instead my extension would communicate with that julia instance via a socket. This would enable some cool things, for example one could execute a specific line of code in a specific module in the julia instance, something that would not be possible if the "send to REPL" command was a stock VS code command that just sent the code via the STDIN/STDOUT to the julia REPL.

I'll have to think a bit more about 2). But my gut feeling is that something along the lines of @weinand would actually be the right design. I.e. the julia REPL is actually started via a debug adapter, and that this debug session is just active for the whole duration of the julia REPL running. The UI of this julia instance would ideally still be based on the terminal UI (the julia REPL is pretty cool and I would hate to lose its features).

I don't know whether there is enough interest in VS Code in the julia community to ever get something along the lines of 2) off the ground, but something like 1) seems pretty straightforward, so I would actually prefer if we could somehow enable that scenario first and then worry about 2) later.

[Krzysztof-Cieslak]

Just small update. We've decided to use Terminal API for F# REPL. Starting REPL spawns new terminal and starts repl in it. Sending line / selection etc just sends text to terminal.

[daviwil]

Same as @Krzysztof-Cieslak, the PowerShell extension is moving to hosting its REPL using the new Terminal APIs.

[Tyriar]

Can this feature be accomplished completely with the terminal API as it stands in v1.6 with the PID of the shell exposed?

[daviwil]

For my purposes, definitely. Not sure about other languages/platforms.

[davidanthoff]

How are you guys starting the REPL for your specific language in the new terminal? I guess I would have thought that the createTerminal function would take the path of some exe that should be started in the terminal, so that I could have made sure e.g. julia runs in the terminal. How are those folks that use this for REPLs actually starting their specific language REPL?

[Tyriar]

@davidanthoff that's available in Insiders (stable soon): https://github.com/Microsoft/vscode/blob/9ad845dbec1c3e84d85ac0c49904e12325534099/src/vs/vscode.d.ts#L3523

[davidanthoff]

Ah, great, I only looked at the public documentation. I'll check that out soonish, but I think that is probably enough for my case.

[Tyriar]

@weinand did you have any other plans/suggestions on this issue or can we close it off?

[Krzysztof-Cieslak]

I wonder if there would be possibility of adding sendText overload which would not print sent text in terminal window. It would allow us to hide some "infrastructure" messages we need to send to F# Interactive.

Also someone complained to me about lack of "clear terminal" action (previously we used output channel which could be cleared), it could just remove all content from terminal leaving only last line (or something like that) ... but I guess that's discussion for separate issue.

[Tyriar]

A clear command was just added as well #6603 which will remove all content except for the current/prompt line and push it to the top.

It's not possible to not show the text as the text it sent as input to the pty process and the pty process sends the output to be displayed, so it's not up to vscode what to do with the output.

[daviwil]

Thanks to the Integrated Terminal feature that got added last year, I think this issue can now be closed. Everyone else here agree?

[Tyriar]

👍