-
Notifications
You must be signed in to change notification settings - Fork 29.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow language extensions to expose a persistent interactive console (REPL) #547
Comments
cc: @mat-mcloughlin for Elixir plugin. |
+1 on this feature |
+1 on this feature. Also, I would like to see an option to see the REPL window on the bottom. |
agreed and this is on our backlog. |
+1 want to run some npm, or nuget or stuff directly from vs code. |
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 :) |
@daviwil @Krzysztof-Cieslak @mat-mcloughlin
Please provide input/insights/ideas in how we could improve the current architecture to support your use cases. Thanks! /cc @isidorn |
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:
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. |
@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. |
Cool! If you can open the same folder in two separate windows then that could simplify the multiple debug adapter situation. |
+1 on this feature (REPL, interactive console) |
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. |
The other possibility in 1.2.0 is to use the new 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 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. |
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. |
I'm investigating this for the julia extension. I generally see two possible implementations right now:
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. |
Same as @Krzysztof-Cieslak, the PowerShell extension is moving to hosting its REPL using the new Terminal APIs. |
Can this feature be accomplished completely with the terminal API as it stands in v1.6 with the PID of the shell exposed? |
For my purposes, definitely. Not sure about other languages/platforms. |
How are you guys starting the REPL for your specific language in the new terminal? I guess I would have thought that the |
@davidanthoff that's available in Insiders (stable soon): https://github.com/Microsoft/vscode/blob/9ad845dbec1c3e84d85ac0c49904e12325534099/src/vs/vscode.d.ts#L3523 |
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. |
@weinand did you have any other plans/suggestions on this issue or can we close it off? |
I wonder if there would be possibility of adding 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. |
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. |
Thanks to the Integrated Terminal feature that got added last year, I think this issue can now be closed. Everyone else here agree? |
👍 |
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
The text was updated successfully, but these errors were encountered: