search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.04k stars 29.21k forks source link

Extract the integrated terminal #34442

Open lloeki opened 7 years ago

lloeki commented 7 years ago

"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.

Edit from @Tyriar:

There is some confusion about the scope of this issue, here is the clarification as the thread is long:

lloeki commented 7 years ago

Hint, hint, call the thing VSterm?

Tyriar commented 7 years ago

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 commented 7 years ago

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

lloeki commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

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 commented 6 years ago

@Tyriar Ok. I'll wait then.

donaldpipowitch commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

+1

RobCannon commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

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

hgouveia commented 6 years ago

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:

and more

my duplicated ticket #55861

songlairui commented 5 years ago

no terminal was better than vscode-terminal

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

LujunWeng commented 5 years ago

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 commented 5 years ago

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

LujunWeng commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@paralin Thank you for suggestion. I did rebase.

nojvek commented 5 years ago

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 commented 5 years ago

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

sagebind commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

When you send the pull request? 😉

MatthewCash commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 notifications@github.com 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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

hgouveia commented 5 years ago

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

image

Tyriar commented 5 years ago

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

donaldpipowitch commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Looking forward to this!