Vscode: Extract the integrated terminal

[lloeki]

"Feature" request.

The integrated terminal grows in functionality, to the point that it could soon become very useful standalone, as its own app. I'm only a casual VScode user (using vim most of the time), but I would definitely be interested in a well-behaved, consistent, reactively-configurable, multi-platform terminal not tied to the editor.

Obviously if such a situation were to unfold, the shared component (not entirely dissimilar to VTE) should be jointly developed and shared with VScode. Both could be able to leverage a common configuration so that whether a terminal leveraging such a theoretical common component is spawned within VScode or standalone, they behave the same.

[lloeki]

Hint, hint, call the thing VSterm?

[Tyriar]

This is an idea I've thrown around a bit, I doubt we'll get time to work on it any time soon. The first steps for this would be more flexible movement of the panel inside the workbench and pulling it into its own window.

[auchenberg]

You should check out https://hyper.is/, also Electron based and extensible.

[lloeki]

@auchenberg I definitely know about Hyper ;) yet Code's implementation is currently much more solid though, and given each one's track record in stability and performance I'd rather bet on Code. Also having the external terminal and Code's integrated one behave in exactly the same way is a non-negligible feature.

[auchenberg]

@lloeki Hyper is migrating to xterm.js build by @Tyriar, which means that Hyper most likely will be similar to the VS Code console. I can't speak on behalf of @Tyriar, but to me it sounds like most of the concerns are addressed by this migration. https://github.com/zeit/hyper/issues/1275

[Tyriar]

Yes Hyper is planning on moving to xterm.js for v2. There will be some differences such as configuration and some things are handled differently (clear in Hyper may not work on Windows for example), overall it will be very close to VS Code though.

[warpdesign]

I can't speak for v2 but the last time I tried Hyper it was really slow & buggy, especially under Windows.

VSCode's terminal implementation worked so good that I don't use cmd.exe anymore.

I understand it's not the priority but if I was to try to extract VSCode's terminal and make it run without VSCode where should I start?

[Tyriar]

@warpdesign what I was thinking was to be able to launch the terminal by itself using code --term or something similar, this would involve:

• Create the "terminal window" which has access to the services used internally by the regular VS Code window (this part would be particularly tricky)
• Modifying the CLI to support this
• Figure out how keybindings and other user settings interact with this special window

Before starting any of this it would probably be wise to get buy in from the team though (and it's not a priority yet so I wouldn't do this yet).

[warpdesign]

@Tyriar Ok. I'll wait then.

[donaldpipowitch]

I can't speak for v2 but the last time I tried Hyper it was really slow & buggy, especially under Windows.

I use the most recent canary and for me it becomes really slow and buggy (disappearing texts, frozen windows and so on) as well, while the terminal in VS Code seems to work really good in everything I tried so far. (Also the copy'n'pasting behavior there seems to work better for me.) Therefor I'd 💕💕💕 to see the VS Code terminal as a stand-alone application as well.

This is an idea I've thrown around a bit, I doubt we'll get time to work on it any time soon.

Are there small steps we can do to slowly iterate to this point?

[Tyriar]

It would be a lot easier if something like this landed in Electron https://github.com/electron/electron/pull/11501, that would allow sharing all the services across multiple windows. Without that, it's hard to think of smaller steps we could take as everything is a pretty big task that might be throw away if the team doesn't like it.

We could try put together a proof of concept in some branch which hacks together the terminal and necessary services, launching via code --term or something. This would be useful to get some buy in and to show it's a compelling proposition. I doubt I'll have the time to do this any time soon though.

I'll be moving on with splitting soon which is kind of a prerequisite to this anyway, we wouldn't want a stand alone terminal that couldn't show more than one instance at once. https://github.com/Microsoft/vscode/issues/7504

In the meantime I recommend hooking up a keybinding to toggle maximize on the panel if you haven't yet https://github.com/Tyriar/dotfiles/blob/7cdd4a9838a0cdec4508a1e484fc603f58c9e1c3/modules/vscode/config/keybindings.json#L19, I use it all the time 😃

[lloeki]

This would be useful to get some buy in and to show it's a compelling proposition

This looks like a sound strategy.

we wouldn't want a stand alone terminal that couldn't show more than one instance at once

Even as a proof of concept, tmux would make this already very useful for me!

[Tyriar]

Even as a proof of concept, tmux would make this already very useful for me!

Still, it's just another thing that will make it even better as this is something on the roadmap that is definitely coming soon 😃

[bijeebuss]

I'm glad this is being worked on. The integrated terminal in VS Code is the best terminal on windows and I would love to be able to use it as a standalone app.

[goldbergyoni]

+1

[RobCannon]

I find that Hyper isn't well supported on Windows. The integrated term in VS Code is the best implementation that I have found and it would be great to be able to use the same terminal everyone that I use a command line. Of course, Windows 10 needs a feature to allow the built in terminal to be replaced by a custom terminal.

[mikemaccana]

This is a little higher priority for terminal users now that Sets was pulled from Fast Ring Windows 10 builds.

Sets clearly has a long way to go - starting a new tab was a slow process of opening the new tab, waiting for edge to start (if it didn't crash) and then searching for the app you wanted to start (another powershell, duh). So right now, tabbed terminals is: wait for a bunch of bugs to be fixed, wait for Windows builds to include those fixes, wait till you can install a Windows build with those fixes. This may be years.

Having a VSTerm would give us something we know works. 👍🏼

[huafu]

40829 has been marked as a duplicate, but I think they are 2 different concerns.

1. This issue, where people want a VSTerm app or kind of (if I understand well)
2. Issue #40829 where the VSCode integrated terminal panel could be "detached" from the main window.

The benefit of the #2 is clear when using dual-screen: tests can be run on another screen while keeping the code with another small terminal in the bottom, WITHOUT loosing the ability to CMD-click on failing tests' paths in the detached terminal running the tests, to directly open their editor in the main VSCode window. I think #40829 should be re-opened as it makes sense it's a different issue from this one.

[Tyriar]

@huafu I'm trying to keep the issue count down, there are several issues relating to this and this is how I see them:

• https://github.com/Microsoft/vscode/issues/10121 Pull tabs out into floating windows - This is a blocker to what you're after
• https://github.com/Microsoft/vscode/issues/10546 Tabs for terminal - This would likely be needed to pull individual terminals out, not the whole panel (not sure if there's an issue for pulling the panel out or not)

Once both of those are implemented you would naturally get the functionality you're after for free.

[hgouveia]

VSTerminal as a standalone app would be excellent

I've used Hyper.Js and Terminus, both on windows, specially Hyper has a lot of bugs, it didn't work properly for me and it was slow, VS Terminal works like charm, very configurable , is fast, and packed with some of the Hyper feature

Current Features:

• Open Multiple Terminal in "tab/dropdown"
• Open Different Terminal (cmd, powershell, bash, etc)
• Split functionality
• Set Custom terminal from settings (terminal, arguments, font, fontsize), just to name a few, i was able to set Cmdr
• Fast!

and more

my duplicated ticket #55861

[songlairui]

no terminal was better than vscode-terminal

期望给个独立款的，虽然这样做纯粹是私人喜好。

[LujunWeng]

Hi guys,

I am hacking vscode to make the integrated terminal a standalone app. Check my preliminary work out: https://github.com/LujunWeng/vscterm. Also, there is an installer for win32-x64: https://github.com/LujunWeng/vscterm/releases.

What I have done:

1. Removed other UI components and only the terminal left. Figuring out ways to remove those UI components' services.
2. I also removed builtin extensions to reduce the whole volume of the repo as well as the size of installer.

Cheers...

[paralin]

@LujunWeng 34,000 commits... did you fork vscode itself? would suggest making a lighter repo for it starting out.

[LujunWeng]

@paralin yes. Basically, I want to keep the history, but it must take long time to clone the whole repo. Yeah. Thank you. It should be a lighter repo.

[paralin]

@LujunWeng You have stripped down the repo a lot, already yeah? If you don't care about history, you can wipe it with a rebase.

Another approach might be to develop as you have for your example app (the extracted terminal) and slowly migrate the terminal code out into another library.

[LujunWeng]

@paralin Thank you for suggestion. I did rebase.

[nojvek]

VScode Terminal as a stand-alone app would be great to have but I can see the architectural difficulties it may present and vscode team may be hesitant to it.

Being able to undock the terminal panel as it’s own maximizable window and switch from dropdown to tabs should allievate a lot of pain.

In multiple monitor mode, it’s nice to have terminal separately on it’s own screen.

[Tyriar]

@nojvek tabs and undocking are definitely on the list of things I want to do in the near future.

[sagebind]

Being able to undock the terminal panel as it’s own maximizable window and switch from dropdown to tabs should allievate a lot of pain.

Agreed. In particular I think that solving #10546 would minimally solve a lot of asks simultaneously in a generic way. For example, moving the terminal to a separate window could be just a second regular Code window with a terminal tab in it.

[sokheangkhun]

I have 2 monitors and I want to dock out the terminal, output and etc which dock on the bottom of the editor to be in my another monitor with its own window which give me clearly space to work. When do I get this feature in Visual Studio Studio Code?

[wrightleft]

I have 2 monitors and I want to dock out the terminal, output and etc which dock on the bottom of the editor to be in my another monitor with its own window which give me clearly space to work. When do I get this feature in Visual Studio Studio Code?

Exactly what I'm looking for!

Not sure that is what the OP had in mind though.

[mikemaccana]

When do I get this feature in Visual Studio Studio Code?

When you send the pull request? 😉

[MatthewCash]

This feature would be amazing. The only terminal I can stand to use is Hyper, and I feel that everyday something about it goes wrong, the text disappears, random errors, or weird margins. I will sometimes open a VScode terminal fullscreen just to use it alone.

[mikemaccana]

@matthewcash I like Hyper and vscode too, but if you want a stable feature filled Windows shell try Terminus. It works (including important things like readline), has iterm themes, defaults to Powershell core, and all the customisability of Hyper.

[Tyriar]

@mikemaccana FYI Hyper, vscode and Terminus all use the backing technology that I help maintain for vscode (xterm.js and node-pty), so the core terminal experience should be pretty similar across each.

When you send the pull request? 😉

Unfortunately this issue is far too large to get externally so I recommend against anyone trying to make a PR.

[mikemaccana]

@Tyriar most of the bugs at a higher level than node-pty - I run practical tests of most of the Windows terminals each month with links to any big issues that stop powershell working. https://github.com/mikemaccana/powershell-profile#prerequisities-for-any-nix-user-who-wants-to-use-powershell

[nojvek]

@Tyriar,

In your opinion, the terminal panel to be toggle-able as a separate
electron window/main workbench is also far too reached to be a PR?

I feel that is an incremental baby step delivers 80% of value with 20%
effort.

On Tue, Feb 26, 2019 at 2:56 AM Mike MacCana [e-mail]
wrote:

@Tyriar https://github.com/Tyriar most of the bugs at a higher level
than node-pty - I run practical tests of most of the Windows terminals each
month with links to any big issues that stop powershell working.
https://github.com/mikemaccana/powershell-profile#prerequisities-for-any-nix-user-who-wants-to-use-powershell

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/34442#issuecomment-467393255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-JVPR9L56wloj1X2Hbbq9ywwE9w4zOks5vRRLNgaJpZM4PYvHw
.

[Tyriar]

@nojvek yes that will be very involved. Our top 👍 voted issue is actually "floating window" support which is essentially that and is on the roadmap so someone will probably investigate this within the next 12 months https://github.com/Microsoft/vscode/wiki/Roadmap#workbench

[Pomax]

I'm not sure why this keeps getting turned into "this is part of turning panels into floating panels". The terminal is special enough that it _doesn't_ need to wait for panels in general to made floating because unlike every other panel, the terminal does not need to tie into, or communicate with, anything else (unlike problems, or output, or debug).

Unlike every other panel, what users do inside the terminal has literally no bearing on VS Code outside of what "running a terminal outside of VS Code" also does (e.g. files popping into existence or disappearing).

While the work to make panels in general would be amazing to see happen, it's also a heck of a lot of crazy re-architecting, and making _just the terminal_ something we can pop out is way easier, and something that doesn't need to wait for a full re-architecture.

This is something that someone with a week of time and enthusiasm could probably do (with guidance, of course), and is extremely worth _not_ treating as "part of the floating panels" work. It expressly is not. It's way easier.

[Tyriar]

@Pomax

it doesn't need to wait for panels in general to made floating because unlike every other panel, the terminal does not need to tie into, or communicate with, anything else (unlike problems, or output, or debug).

This is not true, it touches a lot of components and a lot of components touch it.

This is something that someone with a week of time and enthusiasm could probably do (with guidance, of course)

It could certainly be hacked together by someone with enthusiasm, but it's not as simple of a change as you might think to _do right_. AFAIK the plan is to use the terminal as the starting place for pulling a part of a VS Code window into another window.

I bet I'm more keen to see this done than you are, but we need to wait until it gets on the plan. The best thing you can do it :+1: the issue as that's one of the indicators that feeds into our prioritization process.

[musm]

I see this issue basically also just being able to send code to an external terminal in a more robust fashion.

Could we note take advantage of the new https://github.com/microsoft/terminal to make the "sending code to an external terminal" more functional?

[SHxKM]

Since issues that ask for a "detach terminal" feature are getting closed in favour of this (even though it looks like a separate request), I'd like to note that that's something I would very much like to have.

[Tyriar]

@SHxKM for detaching see https://github.com/microsoft/vscode/issues/10121 and https://github.com/microsoft/vscode/issues/10546

[hgouveia]

Detach is different request, i actually want an standalone app of the vscode terminal, this is terminal is one of the best out there tbh, with nice feature like customization, shell selection, split, tabs

and i would like to be able to use outside vscode

[Tyriar]

@hgouveia what you're describing is what I consider this issue to be.

[donaldpipowitch]

i actually want an standalone app of the vscode terminal,

Me, too. Would also be nice if it could have its completely own extension ecosystem and maybe create a foundation for sharing certain things (e.g. extension handling) so other apps could use that as well. (There seems to be at least "some" interest in this.)

[Tyriar]

The way I see this issue playing out is not having it completely standalone, but allow creating a terminal through CLI args code --term to launch just a terminal not associated with any workspace.

Would also be nice if it could have its completely own extension ecosystem

xterm.js the underlying component for the terminal is just finalizing it's "addon" system in v4, that is the extensions for the terminal itself such that you can build on top of it without putting everything into the core https://github.com/xtermjs/xterm.js/releases/tag/3.14.0. Being able to plug in xterm.js addons through VS Code is not really a direction that I'd want it to go because xterm.js addons run on the renderer, not the extension host (which protects the renderer process/DOM from naughty extensions). They do let you write functionality that could be used in multiple terminals though.

As for VS Code's "base" as a platform, there was a discussion about this very early on and everyone was pretty against it as it means we would lose agility due to having low-level APIs we can't break. Things like new tree view that boosts perf would be much more difficult in such a world.

[nojvek]

code --term would be super nice. I do wonder how much RAM it will end up using. If I have both code and code --term open at the same time in different windows. Does that make two instances of electron with at-least 150MB of RAM/window ?

iTerm uses 164MB for the base and about ~5MB per tab so may be it's comparable.

I know VSCode and especially you care a great deal about memory/cpu/UI lag a lot, unlike slack which ends up using multi gigabytes of RAM.

So excited for code --term when it ships.

[Tyriar]

The base memory usage would likely be much smaller than 150mb as we could avoid creating most of the services, I'd guess around 50-100. I think the memory per tab would be around 5-15mb, but it depends on what your scrollback is set to as we init arrays for the full buffer ahead of time.

[aleksijohansson]

Looking forward to this!

[lolimay]

Any updates?

[wondernate]

Would love this!!! Currently I am using a second instance of VSCode to run my terminal but I loose the ability to link to my current code in the errors.

[Hustcw]

Looking forward to this. VScode terminal is the best one I used in windows.

[gregzanch]

Would love this.

[badelectron77]

This would be great!

[misarfraz]

This would be awesome!

[Giabanga]

Popping out the terminal to a separate window (and even editors etc) for dual screen support is a must have imho. For me, it is the main drawback compared to Visual Studio and other IDEs

[thiefuniverse]

I really want to use terminal in vscode by emacs.... 😃 Terminal in vscode is best terminal I see which is in one editor.

[Ayanmullick]

I see this issue basically also just being able to send code to an external terminal in a more robust fashion.

Could we note take advantage of the new https://github.com/microsoft/terminal to make the "sending code to an external terminal" more functional?

One can configure an 'external terminal' in VSC 'Settings' and open one with Ctrl+Shift+C in Windows. It'd be great if one could point the external terminal to the new Microsoft Terminal, make that the active terminal in VSC and run code from the VSC script pane[F5,F8 etc.] in the Microsoft terminal. Currently, one cannot run PowerShell script from the VSC script pane in the external terminal but I hear it's doable in Angular etc.

[ultraGentle]

In the interim, before a true extracted terminal, would it perhaps be possible to add an option to configure VSCode as the "external" terminal?

Sounds contradictory, but it would work like this: when you open an external terminal, it's actually a new instance of VSCode with the terminal maximized. It could even have all non-terminal extensions off, for the sake of efficiency.

[Tyriar]

@ultraGentle that might be something when can do when we allow the terminal to be pulled out of the main window, chances are it wouldn't use the external terminal commands to do so though. https://github.com/microsoft/vscode/issues/10121

[ultraGentle]

@Tyriar thanks for the response. Just to clarify, I meant that since some folks are already creating a new instance of VSCode just to use the terminal in a separate window, there could be a shortcut for that behavior to mock the effect of an extracted terminal.

It's not a big deal, since that's already easy to do with a few commands in a row (Cmd+N --> Ctrl+` --> Toggle Maximize Panel). Just an idea to fold that process into a single command.

Anyway, no worries, and cheers!

[codepunkt]

When you use development containers, but would love to have your vscode terminal on a different screen, you're all out of luck.

You'd either need a "detach" option for the terminal of the current vscode instance or close the terminal and docker exec yourself into the development container from hyper.

[tigerinus]

Would love to see VSCode integrated terminal detachable and/or able to start it as a standalone app.

Windows Terminal? Before it has some degree of integration with VSCode, I will say: Thanks. But no, thanks. BTW, WT doesn't support bold font which I love about VSCode Terminal.

[darkguy2008]

I know most of you are hyped about the terminal but Windows is GUI. There's plenty of terminal apps (and OSes...) out there if one wants to use it. The main objective of this issue, as I take it and feel it and the reason why I stumbled upon this issue, too, is that it's really tiresome to be resizing the terminal window (or hitting a hotkey) everytime I make a build and need to see a full-screen terminal to view debug output as my current app requires the terminal to display stuff and can't use the debug console (don't ask, it's just like that).

So, the main concern _should be_ detaching the terminal from the VSCode window so I can at least open it in a secondary monitor (I've got 4, go figure) to view terminal output with more real estate to avoid resizing the panel back & forth. I have to expand the terminal to view debug, then resize back to edit, then expand to view my changes, then resize to edit... man, it's horrible.

Windows Terminal, HyperTerm, iTerm, whatever, are all cool, but I think they're outside of the scope of the real issue here.

[VandalPaulius]

I second that. It would be especially useful when having multiple monitors with different sizes and debugging anything on VSCode.

For the quick and dirty way, I wonder if it's possible to write a plugin that just mirrors output from terminal to the other terminal process

[pradhyu]

I really want to use terminal in vscode by emacs.... 😃 Terminal in vscode is best terminal I see which is in one editor.

open a terminal
emacs -nw

I had to fix lots of keybindings to make sure the keybindings in vscode doesn't interfere with emacs.
Just try to use emacs key bindings if anything doesn't work figure out what keybinding is interfering then change the (where binding) condition for that keychord to add && !terminalFocus.

[lloeki]

The way I see this issue playing out is not having it completely standalone, but allow creating a terminal through CLI args code --term to launch just a terminal not associated with any workspace.

Sounds good, except maybe for one UX point: if I'm not mistaken, any update of VS Code would kill the terminals as well. But I'm all for it if it makes the ball move forward.

[lloeki]

So, the main concern should be detaching the terminal from the VSCode window so I can at least open it in a secondary monitor (I've got 4, go figure) to view terminal output with more real estate to avoid resizing the panel back & forth

This use case is definitely part of the discussion (and possibly part of the plan IIUC), but such a terminal is bound to a workspace. This issue right here also covers the use case of having a terminal untied to any workspace (and maybe as a separate program). This workspace-less state kind of exists when you start a new window (which starts a blank, empty workspace which can have terminals started in that state).

I know most of you are hyped about the terminal but Windows is GUI

So is macOS, having a decent terminal is a significant boost. Having consistent, well-behaved terminals throughout the OS is a definite boost day to day. Having such a good terminal available on Windows raises the bar significantly.

I have to expand the terminal to view debug, then resize back to edit, then expand to view my changes, then resize to edit... man, it's horrible.

My current workaround is to use ^` or ⌘J to quickly toggle the bottom panel back and forth (after having resized it to a good enough size) Quake-console-style.

[patrislav1]

Would love this!!! Currently I am using a second instance of VSCode to run my terminal but I loose the ability to link to my current code in the errors.

Relating errors / warning messages to code currently worked on in the editor is also the same use case for me. Right now I work around the terminal limitation by spanning one VS Code window over two monitors, select "Move Panel Right" from the terminal's context menu, and move the panel boundary such that the editor/source tree window is on the left screen, and the terminal on the right screen. That's a ugly workaround that requires both monitors having the same resolution, messes up the window title split between screens, and is not possible in full screen mode - but it's way better than having just the small terminal panel at the bottom.

[WTassoux]

This would be amazing, especially with the latest terminal improvements. VSCode terminal feels snappier than PuTTY !