Vscode: Tabs for integrated terminal

[Perkovec]

Feature request.

Default terminal

But could be more usable...

[Tyriar]

The tabs were originally considered but widely panned by the team as it could cause confusion having tabs at the bottom and make vscode feel less "light-weight". If I didn't have keybindings for focusNext and focusPrevious terminals I would get very frustrated by the lack of tabs since dropdowns are a pain to use.

Also split view was considered and then deprioritized as applications like tmux can run in the integrated terminal to achieve a similar result, I've since pivoted from this and really want to be able to split the terminal. I don't particularly want to learn tmux's keybindings and part of my workflow is to have multiple terminals displaying at once; typically a watch command that I monitor for errors and a manual build or launch command. Let's track splitting the terminal in #7504

@stevencl @bgashler1 please weigh in on tabs again keeping in mind that I could not find reasonable default keybindings for the terminal's focusNext and focusPrevious actions (I bind ctrl+shift+j/k).

[stevencl]

We need to consider this in the context of this issue though: https://github.com/Microsoft/vscode/issues/9659

I'm really wary of a tabs within tabs design. We'll end up just using all the available space to show tabs :-)

Just thinking out loud here, do we really need to show tabs if we allowed splitting the terminal? Would it be enough if we just exposed actions to split and collapse the terminal but didn't have to show the actual tab?

[Tyriar]

Maybe, I can see myself using 2-3 split terminals over tabs/multiple terminals. Managing split terminals and tabs terminals would get very confusing and probably barely get any use due to lack of keybindings.

[bpasero]

If we open the door to splitting terminals, what would it mean for splitting e.g. one terminal and one debug repl? is it the same UX interaction?

[Tyriar]

@bpasero by splitting I mean create a new terminal to the side, so yes it would be the same.

To simplify the interaction there could be a setting to always use _either_ the dropdown or split the terminals. That way all the existing commands would still work fine, you just choose to show 1 or all terminals at any time.

[bgashler1]

The fear I have with introducing tabs and splitting to the terminal is that it may look like an editor group. I don't want users to be disappointed that they can't drag editors into the terminal or terminals into the editor groups.* Also, introducing this may be a slippery slope in window management, such as why do we even have a special horizontal panel for things like this in the first place. Why not just let a terminal live wherever it wants, instead of replicating so much functionality in custom UI.

*possibly we could inform them of the limitation by locking dragging on the x-axis and/or having a disabled-cursor when trying to drag outside an area, but it's difficult to avoid people expecting this to work.

When we introduce horizontal splitting of editor groups, one of the constraints we're imposing is that editor groups can only be horizontally split or vertically split. So it may be uncanny for users to have a panel that looks strikingly similar to a horizontal editor group (but it doesn't behave exactly the same way) sitting below vertical editor groups.

We should talk more about this during UX sync on Wednesday. There are some designs I didn't show last time related to horizontal layouts that are relevant to this

[nick-walt]

What about the option of aligning the terminal with the editor tab, so that the terminal automatically reflects the language of the editor file?

Opening a terminal would automatically load a preconfigured shell for the active (currently selected) editor's language. Multiple terminal shells must be supported in the settings.json file.

It doesn't matter how the editors are split - the terminal always shows the shell for the selected (active) editor. This is simple and straightforward. With this method there is no need to split the terminal, no need for tabbed terminals. The terminal would continue to appear as it does now.

If there are multiple shells available for the language, or you want to run a configuration like node shell and a git shell for the one editor tab, then perhaps the shells can be selectable within the one pane. This is a bit like tabbed terminals, except they are not presented as hard tabs, which implies a sub-context. This doesn't 'feel' substantial like a tab. Their context is within the terminal pane for currently selected editor.

A simple hypertext string (one for each shell) located in the top right of the terminal will show the shells open (instantiated) for the currently selected editor. A user can either just click on a hypertext string, which might say node, to select it, or use a key binding to cycle through. These will replace the existing drop-down menu, the +, and the trash can. The shells could possibly be presented in lowercase.

Either a simple hypertext string could be shown or just an icon - although, a string might be better. This would replace the cumbersome drop-down list currently used in VSCode and show the shells at a glance.

When you switch focus from the current editor, to an editor with another language (say, Ruby), the terminal will present the IRB instance in the terminal. If the user wants to open another instance of the current shell they might only have to hover over the hypertext for that shell and click the + that will appear. If the hypertext strings are short - like node, irb, cmd, ps - another string can be created next to the string used to create the new instance. The strings would move apart to make room but wouldn't become cluttered because a limit could be set (who is going to open more than three shells against an editor?).

Hovering over a shell might also be able to present a peak, that shows the shell content for that string. Though, if users are using key bindings to switch/cycle it might just be easier to check with that.

If you wanted to give the user the option to add a shell not associated with the editor, like a git shell, clicking the + could present a menu of shells registered in the settings.json file. The - that would appear on hover next to each hypertext string would, of course, not show any options. It would close the current shell instance.

If a user wanted to change the shell type, they could exit from the shell (to fall back to the default) and then launch a new shell by typing the shell name. The hypertext string representing the shell would change to reflect the new shell.

In the case of a git shell, it might be logical to offer the option for the user to specify that a git shell will always be opened with the editor's language shell, so that git is in context to that file location. If multiple files are open from the same git location, all git shell instances across all editors will reflect the latest update or command.

The settings.json file will likely require the user to enter the specific language extension (.js, .cs, .rb) against each terminal.internal.shell. entry so that there is a logical match up to a file. A default shell can be configured for any file type not specified in settings.json.

The shell instance loaded for each editor lasts as long as that editor is open. As soon as an editor (a file) is closed, the associated terminal shell(s) are also closed.

I believe that this is a simple implementation that will also make VSCode more powerful than it currently is, while being very intuitive. When the user switches contexts across language editors they don't have to think about the terminal. The terminal will always present the shell and the code last run, including the associated history, etc, that was last used for the selected editor.

[Tyriar]

@nick-walt while it may be more intuitive to some, it's not at all intuitive to others. It would likely cause people to get somewhat disoriented and wonder where their shell went. Also my requirements are to have 2 shells displaying at once; one for a watch task that I'm tracking errors in and one for a launch task, git, build, etc.

Multiple terminal configurations has come up before, I'm not so sure it's worth the additional complexity though when most of the time you can just run the shell in your other shell (opens powershell, ruby, node, etc. within cmd).

[nick-walt]

@Tyriar
Those are good concerns, but I think that they can be solved fairly easily when taken on as considerations.

Avoid disorientation
In its default state, in an unconfigured new installation, the terminal can behave in a familiar way. This avoids disorientation from an unexpected behavior.

Splitting the terminal
Splitting the terminal pane doesn't change the model. It's just a way to view more than one shell in the terminal pane at a time. It could be possible to drag the pane out of the main window and go full-screen on another monitor. Then the user can tell the terminal to split automatically and evenly between the open shells, vertically or horizontally. One terminal, multiple shells - all in context with the currently selected editor.

Watching
If we don't want to lose sight of a shell instance that we're watching, while you switch to another editor, then perhaps a watch feature that shows a configurable number of lines could solve this problem. If an error occurs this can also be shown as an icon in case the user missed it due to fast scrolling. This is already done in VSCode's Error pane. A watcher panel could be display only and hovering over it could show a bigger sample.

Sophistication without the burden of complexity
With a contextual terminal the ability to have many shells across all of your editors won't feel overwhelming or taxing. Given the right model the UI/UX guys can make it work elegantly.

I think your concerns could be fully addressed.

[whitecolor]

It depends for what terminal is going (supposed) to be used. If it is going to be used to run some one time command then multiple terminals are hardly needed in any manner.

Multiple terminals are needed if they are going to be used to run concurrently multiple background tasks, such as serving, building, watching, tests etc.

So in this case it is viable to have quick overview what terminals are opened and what they are running (with presumably the state of the run). I'm not sure how it can be done without named/maked tabs.

Split view is also needed because on wide screen there is available place at least for more then one terminal.

One more question is cooperative use with task runner. Which is currently used to run only one task at a time. But this https://github.com/Microsoft/vscode/issues/981 assumes that it is going to support multiple background tasks - so it is a like (I wouldn't say conflicting) purpose as for multiple terminals.

Jetbrains Webstorm currenlty has such capabilities - it can run multiple tasks (defined via grunt/gulp/npm) and multiple terminals (with named tabs). And you also may use there a split view where one one side you see running tasks, and on the other - terminal. (attaching the screen)

[nick-walt]

@whitecolor

Okay, so if we list all of the scenarios and their commonalities it should be possible to distill the required functionality to elegance that can address diverse usage - without VSCode becoming too heavy.

Much'o tabs without fatigue
With a terminal bound to the context of an editor the issue of a usability disconnect (such as which tabs associate to which editor) the use of 'soft tabs', aka a hypertext string naming the shell within the terminal/editor context, will allow many more tabs without causing the user to go tab hunting and avoid context/association fatigue from keeping track in their head.

Named shells
With the idea of a simple hypertext string showing the name of a shell instance within a terminal pane comes the possibility of an alternative creation and naming. So, a user has a single shell configured in settings.json, which might be 'cmd'.

Once they are in a shell they can either jump into another shell, like 'powershell' or 'bash', and the hypertext string named 'cmd' in the terminal header can change to reflect the shell in which the user jumped to.

Or, the user can create an additional shell instance from the starter 'cmd' shell maybe by using a command the terminal pane understands as creating a "new ".

The idea is to imply in the UI the fact that the named shells are not dis-associated tabs but shells within the parent editor. I'm using the term 'tabs' to denote a dis-associated and self-contained shell that is separate to anything else. This could be a mode, where hard-tabs are global, and soft-tabs are within an editor context.

If a hard-tab/soft-tab mode was included then perhaps the hard tabs could have hard boarders, much like tabs showing editors. The behaviour of the names would be identical to soft-tabs.

The critical thing is to maintain the established UI/UX model. We've all seen plenty of instances where models are broken across different UI implementations within a single app. Actually, Microsoft is good at this (and more of late, Apple). It's a classic case of 'design by committee'.
established

Simple, single shell user
However, if a user wants to run simplified and a single terminal/shell then there is nothing in the way of achieving that, and importantly, the configuration is simple. It's just another usage scenario in the consideration matrix.

[W4RH4WK]

If tabs are going to be added, I'd like to have a config option to disable them / force a single instance of the integrated terminal. If I require such _advanced_ features, I typically resort to using the (external) terminal of my choice.

[whitecolor]

I would aslo consider such thing as terminal split (more advanced split) so all the running (maybe more then two) important terminals outputs where before the eyes even partly.

[cescoferraro]

How about showing the terminal tabs at the same place as file tabs?
It would not polute the UI and no functionally would be lost.

[christianmalek]

@cescoferraro I like this idea. But then VS Code should also support vertical splitted tab views and not only horizontally. Otherwise it wouldn't really meet the condition to see multiple terminals without wasting space.

[cescoferraro]

@Phisherman Do not get me wrong, I like the split terminal.
I use it a lot on Intellij with a big screen and lots of memory setup.
Whatever the decision is, it should be pluggable if hogs to much memory to keep VSCode as fast as possible.

[whitecolor]

I've wrote an extension with that you can select npm/gulp task, it will launch the terminal (with task name) and run it there, also will place an item on the status bar which you can click any time, as well it does basic tracking of the running process state.

Just to show possible "tabs" location, they could be at the bottom of the teminal.

[Tyriar]

@whitecolor :open_mouth: this is using the new terminal API? That's awesome!

[whitecolor]

@Tyriar Yeah, that one you are working on :wink:

[linvi]

As mentioned by @whitecolor, WebStorm do have tabs for terminals and this improve the accessibility of the IDE. In addition to this WebStorm allow you to change the name of the tab which again help you to visually identify what to start.

Something that WebStorm does not do though is that it does not save the number of terminal tabs open.
When you develop you usually need the same tabs (server, watcher, backend...). If the number of tabs could be saved as well as their name it would be awesome.

[Tyriar]

@whitecolor after thinking about it a bit there are a few problems you will run into with the current API in implement terminal tabs that way, assuming you're exposing an extension "create new terminal" command that you want to override the default one. Here are some issues you should track if you're interested in building an extension like this:

• When vscode is restarted a standard terminal will be created, you cannot attach a status bar item to this
• The extension is unaware when a terminal is disposed by the user, so the status bar item will stick around at least until clicked again #10925
• (Bug) Disposing a terminal will show the panel #11275
• Also coming up in v1.6.0 probably the terminal will likely be hidden by default, so you'll need to call into Terminal.show right after creating it #11384

[whitecolor]

@Tyriar thanks for sharing, will answer to you list:

1) Yes it is not so important, my extension actually adds a command "Open new terminal" and allows to open new named terminal, I usually just close standard, and use created one, but it would be good if there was an access to all existing terminals in the panel.
2) Yes extension is unaware about terminal state but I track child processes of the terminal._id by PID, So I know when terminal is disposed by user (child processes go to 0). So what I would ask not to _remove_ this process id in future, not sure if this need to be public). So I even track the amount of running child processes and if the count is reduced this may mean that something wrong or tasks has finished running, then I show this terminal, quite useful.
3) So I don't use currently dispose.

What really is lacking is access to process output, that would allow to make more useful analytics (for example track some error/exceptions output) and show the terminal to the user.

Extension is actually ready do be published, probably will do this on days.

[Tyriar]

@whitecolor currently there is only access to terminals created via the API, this is quite a compelling case to change that though.

Sneaky sneaky peeking at terminal._id :wink: it probably won't be changed anytime soon but as soon as an event you can listen to is added you should definitely leverage that as it will be the official stable API. Child process tracking and output is to be explored in #11422 (you can follow the issues linked to from that for some discussions on the topic).

With the named terminal command you're also providing a workaround for #10023 :smiley:

Nice work, looking forward to trying it out!

[Tyriar]

@whitecolor FYI, so I lied and terminal._id will probably change in v1.6 to be some random ID, not the PID. I'm in the middle of a huge refactor in order to separate the terminal panel from the processes more (so they can exist without the panel existing #11275) and I don't think I can keep it there unfortunately.

[Tyriar]

@whitecolor you can try out window.onDidCloseTerminal (#10925) in tomorrow's insiders. It should be easier than tracking the PID.

[equiman]

I wold like to see it like InteliJ. Until this, I add it this personal keybings:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

The same keyboardshortcuts to navigate between tabs, but if cursor is focus on terminal toggle between terminals.

[MeirionHughes]

Split view on the terminal tabs would be super useful;

I'm currently trying to do proof of concept with a server instance and executing requests via another console terminal.

Any progress on this?

[whitecolor]

@MeirionHughes
tmux could be a solution but it works ungly inside VSCode integrated terminal (at last in windows).

[Tyriar]

@MeirionHughes here's the issue for that feature https://github.com/Microsoft/vscode/issues/7504. No progress so far, last time I pushed for it I got push back from the team. The more :+1:'s on that issue the better though.

[MeirionHughes]

@Tyriar you could say this this issue is also asking for splitting, as in the third image it explicitly shows it. Plus this issue has 112 👍 :)

[Tyriar]

@MeirionHughes the first comment (mine) says:

Let's track splitting the terminal in #7504

The reason for this is so that the discussions for 2 different features are not creating noise for each other.

[alexmarch]

Oh guys, pls help as it really important UI feature, sometimes it make crz handle dropdown to switch console, thanks a lot ;)

[eckdanny]

+1 for cycle terminal keybindings.

@whitecolor _darn!_ I thought tmux within integrated terminal was my own clever workaround, but u beat me to it. Works fine for me (no mouse mode) but panes working fine:

[danielo515]

Mouse mode is working fine for me with tmux.

In any case, I think this is a great addition

[TryingToImprove]

I think this would be really useful. But I don't think that it should limited to terminals, but also include the "Problems", "Output" etc. tabs, so you can have "Terminal", "Problems" and a the editor open in one view.

[psimoneau22]

Im also going to just +1 on a keybinding to cycle through the terminals. I hate having to use the mouse to click that tiny dropdown, especially on a laptop with a track pad.

Give me a keybinding to cycle through terminals and I think I can do without the splitting/tabs

[Tyriar]

@psimoneau22 this is the keybinding I use for that:

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

We're going to be looking into splitting soon.

[danielo515]

I can't believe how good and powerful this editor is getting. This will be a super powerful addition to just open vscode and nothing else during a coding session.

[vviikk]

TL;DR; Use a few hours to pick up tmux.

I'm happy with tmux in my terminal (mouse mode works like a charm). It took me a day to learn. I've played with it before a few times, but I spent yesterday setting it up like a boss. I just do a tmux -CC in iTerm - which launches a terminal window. Then do a tmux a in the vscode terminal to hook onto that session - this was I get persistent terminal sessions so I can always get back by session when restarting vscode (update Vscode, install extensions). This is a much better feature for me than having tabs or splits in the terminal. Keep Vscode light please. Atom is a lesson to learn from (I came from it). TMUX FTW :)

This same approach has also worked for me in Mac / cygwin / windows and should work pretty much everywhere Vscode runs.

[FrancescoBorzi]

TL;DR;

it would be nice to have tabs for the Integrated Terminal instead of the dropdown. Any chance to see this feature in future?

[leocaseiro]

Considering the shortcut ctrl + shift + ` and ctrl+` I believe these settings make more sense.

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

[saborrie]

@leocaseiro @Tyriar @psimoneau22 Unless you're using a Mac, it's worth adding the 'when' option to those as ctrl+shift+left and ctrl+shift+right are used to select text chunks in the editor.

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

or

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

[MikeGitb]

Here a my 2ct for this highly desireable feature (sorry if some of the points have already been mentioned)

Use cases
The reason why I use multiple terminals in the first case are usually either:

• I need to work in two directories in parallel and don't want to cd forwards and backwards all the time
• I need to work with two different terminals (e.g. bash vs powershel vs cmd or local vs remote / ssh)
• I want to monitor the output of two different programs in parallel

Note that only in the third case I need a split view of the terminal. In most other cases I prefer to have one terminal using as much space as possible.

UI
Why not extend the current tabs (e.g. Debugging, Ouput, Terminal ...) and allow an additional "Terminal1, Terminal2, Terminal3 ....)

Tabs vs Drop-Down

• You see all availabe tabs
• It is easier (for me) to remember which terminal serves which purpose if they are represented by distinct visual locations locations (e.g. 3rd tab)

[kevinxh]

tl;dr

I strongly agree with @MikeGitb , I always use more than 1 terminal at once. The dropdown for terminals in the current VS Code is hard to see open tabs. It would be really awesome to have tabs for integrated terminal. Thanks.

[MikeGitb]

One crazy Idea: why not give the terminal the same status as regular editor tabs? Would be especially handy if one wants to see more than a couple of lines at the same time.

[whitecolor]

One crazy Idea

It is not crazy, this how vim/neovim work.

[MikeGitb]

It is not crazy, this how vim/neovim work.

As do a lot of other IDEs ;).

Sorry, that intro was actually meant ironically.

[ajrator]

@Tyriar is there a feature to allow vertical paning of the terminal alongside your code or will this not be allowed?

[Tyriar]

@ajrator that's covered in https://github.com/Microsoft/vscode/issues/2806

[mikemaccana]

Would be totally happy giving terminals the same status as editor tabs - ComEmu and HyperTerminal both have serious issues that prevent their current use (ConEmu has contrast issues that can't be fixed as the maintainer wants to keep XP support, HyperTerminal can't do Ctrl+C in powershell and other basics). Having vscode as a working tabbed terminal would be fantastic.

[katturajam]

I am also keep watching when it will publish tabbed view of integrated terminal instead of dropdown.

[ghost]

Dropdown menu is a bit uncomfortable to use. Also having more than one open terminal would be great.

[cybertim]

For people who would like to try tmux while waiting for tab support I created a gist to kickstart the setup. It has mouse support enabled by default and uses simple bindings to split the terminal.
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

[ghost]

Thanks @cybertim, great file! I used tmux already but this file is handy.

The reason I personally would be quite keen on multiple terminals at different position within the window is that hopefully it would lead the way to implementing RStudio/Jupyter Lab like environment within VSCode.

[joshua-barnett]

Personally I would like everything to be a tab and then provide the ability to split panels infinitely vertically and horizontally. You could then also provide the ability to pin tabs in order to keep the most commonly tools e.g. Terminal, Explorer, and Search.

[vviikk]

Older editors have the save, undo, redo buttons along a long toolbar on the top - VSCode doesn't - why? Because it's expected that people would use the keyboard. We're programmers. Previous-terminal, next-terminal all can be bound to shortcut keys - use it. I say we close this issue and move on with what's important.

Next, still want tabs? Panes? Splits?

I think many folks here are requesting a feature that is overkill for VScode. If they would just give tmux a go, they would not be asking for this. The terminal is given to us. Using tmux, it supports tabs. You'll take a couple of hours max to learn tmux. There's tabs, windows, splits, and more so, if you need to restart VSCode you can just type tmux -a after it restarts to go right back into your tmux sesion. After switching on mouse mode (just one line in the config), you can even resize panes, click on tabs to go to that tab. I am against this feature in VSCode. It's only going to slow the performance. Keep VSCode as lightweight as possible - we don't want another Atom. Let tmux do the heavy lifting! As you can see below, I have splits and also if you look closely at the bottom, I have two tabs - python & fish. And yeah, at the bottom left, I use googler in the command line to Google :D

[saborrie]

@piggyslasher I don't see how this feature could make vscode slower.
Vscode already supports having more than one terminal instance. This feature is just about changing the dropdown chooser to a hopefully nicer to use tab feature.

With this feature you'd still be able to carry on using one terminal instance/tab with tmux, and would not expect a change in performance compared to now.

[danielo515]

Vscode is a multi platform editor. Telling the people to use tmux is restricting those people to environments where tmux is available. Also tmux has a big learning curve that is totally overkill for a feature as simple as this one

[sorahn]

@piggyslasher's suggestion is interesting though if you think about it rather like 'do it the tmux' way.

This is something I've been thinking about for a long time. Tmux has tabs and each tab can be split in to as many panes as it wants. Editors in contrast have panes and then each pane can have tabs.

I rather like the tmux way because it's like 'this layout of terminals is related, and then we switch to another tab of related terminals'

For something like react/angular development, I could see this being useful if you have a JS/HTML/CSS/Test 'pane' open for each component, and a 'tab' for every component you're working on.

I'd be interested to see if it was possible to do something like that in a plugin. Origami for Sublime is close, but it's still 'panes full of tabs' not 'tabs full of panes'.

[nick-walt]

There is a lot of concern about scope and scale of introducing console management via tabs and other UI mechanisms and I just want to point out that if the problem that is being solved is defined very clearly, scope and scale blowout and user expectation issues are going to be mitigated due to the elegance of the solution. Define the problem very clearly and the solution is going to be clearer, and the logic is more likely to be consistent throughout the UI and UX. You know, that sense of "it just works" which we all enjoy using and creating.

Also, it would be good to have a bulleted or numbered list of the different solutions offered in this thread and their identified concerns (probably as indented-bullets/numbers). A thread like this can go around in circles without these things updated in a central, curated location, or perhaps in the initial post.

Seems to me that everyone agrees that some form of console management is required, beyond what is currently in place. Just a suggestion to solve scale problems: provide the option for the user to attach the consoles to an editor, or a group of editors. Allow also for a console to be separate, but make either way a user defined default in settings. Attaching the consoles to the editor context will help to reduce excessive spawning of consoles. Plus, it will allow the consoles of one editor to be hidden when another editor is selected, keeping UI complexity down. If consoles aren't associated with editors things can get out of hand and people will forget which console is doing what, etc.

Consider adding a user configurable setting that enables the consoles defined for an editor to be saved in the app, based on the name and location of the file (or, maybe based on some other, more reliable and unique identifier in the file's properties at the system level).

The argument could be said that this level of refinement is approaching IDE levels but the creators have already said that VSCode brings some of the good things of an IDE into the editor space. It is possible to introduce a console solution that doesn't feel heavy or complex, that just works while bringing excellent UX.

If this doesn't make sense, or if I am stating the obvious, let me know.

[saborrie]

@nick-walt when you say:

provide the option for the user to attach the consoles to an editor, or a group of editors.

Are you suggesting an ability for the terminal to associate shell instances with particular open files?

Sounds to me like you're over-complicating it. Of course keep thinking outside the box about it, but from what I've seen on similar features, the vscode team likes to keep the impact of small features like this quite minimal. So I'd bet they're looking for the simplest (while still effective) solution to make people happy.

The most basic point of this issue is that a dropdown menu isn't great for switching between things, and that tabs are a pretty good alternative - hence why most things use tabs: editors, IDEs, browsers etc. I think everyone here would agree that essentially any form of tabs would be preferable to a dropdown.

Besides that most basic part of how we switch between shell instances, there is an interest in also allowing some way of having more than one instance visible at the same time. Either through panes in the terminal section at the bottom, or by also making terminal tabs interchangeable with editor tabs in some way, or some other solution. This part is more complicated, and there is probably less agreement on which way to go. Especially given what @sorahn has just pointed out about panes-inside-tabs vs tabs-inside-panes.

Personally I think there's enough support to just go for removing the dropdown (because it is really not great) and replacing it with tabs, and worrying about more advanced stuff afterwards.

Over a year ago @bgashler1 said this:

The fear I have with introducing tabs and splitting to the terminal is that it may look like an editor group. I don't want users to be disappointed that they can't drag editors into the terminal or terminals into the editor groups.* Also, introducing this may be a slippery slope in window management, such as why do we even have a special horizontal panel for things like this in the first place. Why not just let a terminal live wherever it wants, instead of replicating so much functionality in custom UI.

So maybe at this time it is best to consider tabs which are visibly different to editor tabs, indicating that they are _not_ interchangeable with editor tabs, to avoid any confusion?

[nick-walt]

I agree, Tabs are a pretty good solution to selecting different consoles.

I think the way to enable the functionality of associating consoles with an editor would just be via changing a user setting. Once enabled, opening a console while an editor is selected could create the association. As simple as that.

The UI would most likely be that when a new editor (file) is selected at the top of the application the console Tab(s) at the bottom change as the editor changes. It's pretty simple and intuitive.

I think it would only become more complex if they add the ability to associate individual consoles with more than one editor, based on some user context, such as:

• directory location
• project
• file type (maybe when the files are in the same location)
• editor grouping (user defined)
• some other abstraction

This experience would be that the specified console remains the same whichever editor in the context is selected (or, remains the same because the user wants all consoles to be available to all editors).

How the UI is presented is where things need to get creative in order to avoid the feeling of complexity and keep it feeling intuitive, quick and easy to use. With good UI design the complexity is only there for the team creating the feature :)

[nick-walt]

To reinforce a console tab's association with an editor, the pane which contains the console tabs would be clearly labeled with the name of the editor.

And each tab could automatically display the type of console loaded, such as Git, Node, CMD, Powershell... instead of displaying Terminal 1, Terminal 2, etc ( as showen by @Perkovec ). This would be automatically generated by the application.

This will allow the user to select directly the console they want without hunting across the tabs looking for that git or powershell prompt.

The other option is to provide the basic tab engine in the application core and allow users to add an extension of their choice to add more capabilities to console management. At some point, the features that get used a lot can be rolled into the core app.

[MikeGitb]

If I understand you correctly, I'm strictly against associating terminal with editor windows. Most of the time I don't have a fixed relationship between editor tabs and terminals and when I do it is certainly not a 1:1 mapping (usually not even 1:N).

[nick-walt]

@MikeGitb I would guess that, depending on the weight of user preference, the default association of editor with console setting might be either enabled or disabled.

Some might want to mix both, depending on what they are doing and what console they are using. This is just a refinement of the UI/UX problem that the creators would have to work out. Same as for any UI/UX challenge.

The use case for contextual editor/console UX is going to be:

• no context (no consoles associated with any particular editor)
• mixed context (some consoles associated, some not)
• all context (all consoles associated with an editor)

BTW, I'm suggesting the association of a console with an editor as an option to minimise console tab proliferation (and unwanted confusion/overhead), which was a concern voiced by a few people. With a contextual editor/console UX, the associated consoles will most likely be hidden as soon as an editor in another context is selected. The user is always only viewing what is relevant to the selected editor.

As usual, the UI implementation is going to make or break this kind of thing. The VSCode team have already done a pretty amazing job with UI and there is no reason to think that they could not figure out how to implement a more sophisticated console management experience without making things feel complicated and overloaded.

As we have all experienced before, and increasingly so with newer software, it is very possible to expose the user to a significantly higher degree of complexity and sophistication while making the experience easier and feel simpler.

[MikeGitb]

Just to understand your use case: may I ask, what kind of operations you perform on the terminal, that are bound to a specific file, as opposed to the project/directory?

My typical use cases are using git, compiling my project, executing a binary and viewing some trace output. All of them are independent of which file is currently open, but I'm using it primarily for c++ projects or single file edits, so other areas might require different workflows.

[saborrie]

Pretty sure almost everyone uses terminal instances independently of the editor tabs. Such a feature would be better off as an extension.

[nick-walt]

Yeah, I agree with extending the console experience with extensions. Probably the best way to open this area up to development.

Creating a console engine in VScode for everyone to build upon would be an interesting experiment.

[plmrry]

Here's a clip of how the Cloud9 IDE works:

It seems to have what many of us seem to be looking for: Any new tab can be either an editor or a terminal, and any tab can be moved and split horizontally or vertically.

[nocksock]

@plmrry That's awesome! Something in that direction would be reeeaaally nice.

[Tyriar]

@plmrry the question of whether we would go to have a very flexible pane system like that is still open. I personally like how the panel is fixed, this makes the terminal commands very clear what will happen; focus terminal will always open the one terminal space and focus the active terminal.

If there are multiple terminals in editor tabs, some in the foreground, some in the background, then the question of what certain terminal commands do is not as clear and will not be as intuitive.

[btoo]

can the terminal commands just target the one that was last focused? much in the same way that cmd+shift+t will target the tab that was last closed

[Tyriar]

@btoo that's probably what it would do in such a world. That is a very radical change in how VS Code works though.

[vedmant]

I come from PHPstorm and lack of terminal tabs is really frustrating, all Brainstorm products have terminal tabs, it's very useful feature.

[gtarun]

Indeed a useful feature, I would request the developers to add it, this will make the life easier where we need to monitor more than 2 things at the same time, I really like the idea @plmrry

[PixelT]

+1
tabs in terminal are more UX friendly than select and do not take a lot of space

[mllanes]

+1

[AnthonyMichaelc]

This is part of the reason I still use iterm and cmder split screen since I am able to see more than one at a time. Makes sense that vscode can currently run multiple at a time, which adding the ability to display both at the same time (whether it be split horizontal or tabs should not interfere with performance).

If there was going to be a performance issue with that then vscode would also freeze if i ran npm run server in one tab and mongod in another (or whatever the multiple commands someone may need to run).

[Tyriar]

Small update on this: I'm currently consumed with making the terminal accessible (https://github.com/Microsoft/vscode/issues/8339), after that the next major piece I'll be working on is probably going to be terminal splitting (https://github.com/Microsoft/vscode/issues/7504) which is was forked off from this issue (and is likely what many of the people upvoting this really want). This is on the roadmap https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

@AnthonyMichaelc there's no performance concern with showing multiple, the terminal is super fast after the recent improvements.

[mikemaccana]

(splitting) is likely what many of the people upvoting this really want

@Tyriar I upvoted tabs because I want tabs, not splitting. I suspect most of the other people also meant what they voted for - a vertically or horizontablly narrow terminal doesn't do it for me.

[ericblade]

... I just read through all of those, and I can't believe I missed this idea:

Why not add additional tabs to the existing tab bar, when new terminals are opened?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... also, debug console isn't terribly useful if you're not actually using the debugger .. just an aside.

[PixelT]

(and is likely what many of the people upvoting this really want)

I will paste only this.... (first post in this topic)

[dreamair]

In addition to @ericblade's comment, please let me see at least 2 panels (problems, outputs, consoles, terminals,...) at the same time!
For example while debugging a server I would like to observe the output of some other service or the file watcher building my client without switching views all the time, not even via keyboard short cuts.
I would happily welcome split terminals (also on Windows ;) as a start, but flexible tabs placable in the left/middle/right panel would improve the "observation deck" of vscode considerably without cluttering the UI.

[mikemaccana]

@PixelT The first image in the post you're quoting is with tabs added, exactly as the title says. Maybe file a seperate PR and link it here for splitting?

[PixelT]

@mikemaccana please read with understanding my post once again, because I see you don't understand it + I didn't remove anything :]

[mikemaccana]

@PixelT You're right, I mistakenly thought you'd removed a picture - sorry. That said: the title and the first suggestion is tabs rather than splitting, and a seperate issue for splitting would be good.

[Tyriar]

@mikemaccana splitting: https://github.com/Microsoft/vscode/issues/7504

[andrejarboe]

Could we have the option to have tabs but turn it off by default?

[Tyriar]

A preview of splitting has landed in Insiders, check out https://github.com/Microsoft/vscode/issues/7504#issuecomment-365683609 for the full update.

[AnthonyMichaelc]

I think this is definitely a step in the right direction. I am sure someone will complain why can't I put 15 terminals in but for me having this and would great. If working on something like a mean stack I can have one double terminal for just the nodemon and mongos etc and then open another terminal pair for running the ng serve and generate commands.

Now if the stable vscode version had this option and the other feature request of having a grid layout that I've been waiting for all dreams would become true haha.

Side note: I noticed only from using for a few minutes if I try to switch back and forth opt/alt +cmd/ctrl quickly the focus seemed to be just behind a little. (May just be me)

[Tyriar]

@AnthonyMichaelc

I am sure someone will complain why can't I put 15 terminals in but for me having this and would great.

The plan is actually to allow as many as you want, I only solved the problem for n=2 so far though.

grid layout

We're actively discussing this now, it's even got a place on Feb's iteration plan https://github.com/Microsoft/vscode/issues/43361

Side note: I noticed only from using for a few minutes if I try to switch back and forth opt/alt +cmd/ctrl quickly the focus seemed to be just behind a little. (May just be me)

I haven't seen this yet but I'll keep a look out for slowness.

[Morkowski]

@AnthonyMichaelc

If working on something like a mean stack I can have one double terminal for just the nodemon and mongos etc and then open another terminal pair for running the ng serve and generate commands.

Having multilple terminals and editor at the same time is very comfortable. In my daily life I have first terminal for development server, second for unit tests and sometimes third for git.

There is a hacky way to archieve this in cmder terminal for Windows by opening VSC as one of terminal tab (here) I can't wait for native solution for Visual Studio Code, becouse there are some problems with shortcuts while using VSC and Cmder in this way.

[PixelT]

@Tyriar as I can see, this topis is about tabs in terminal, no splitting... ?

[Tyriar]

@PixelT it's clearly related. Many people have stated in this issue about being able to see multiple terminals at the same time which splitting will solve for the time being, so they will find it useful.

[PixelT]

I can't agree with you - this topic mainly observe & discuss people who want tabs in terminal, for splitting terminal there is another topic: https://github.com/Microsoft/vscode/issues/7504 which you created :)

[webia1]

Terminal Tabs & Splitting are today standards in almost every modern IDE.

[jamesjryan]

Switched to Insiders build to test this, works amazingly, thanks @Tyriar !

[PixelT]

still nothing happen about tabs in terminal... 😕

[AnthonyMichaelc]

@PixelT Have you tried the insider version that has the dual terminal? From what they said they plan on making it so you can open as many terminals in that layout as you want but I believe the insider version currently allows 2 with the command: cmd/ctrl+d I believe

[AnthonyMichaelc]

@Morkowski I see what you did.Yeah I have a windows and an osx laptop so when I am on the windows computer I do use cmder like that, when on the osx computer I user iterm and create at least 2 to 3 inside a grid layout and 4 when working in a mean stack application.

[jamesjryan]

Hey @Tyriar bit of feedback - when resizing the console using the Maximize Panel Size or Restore Panel Size buttons (or a keyboard shortcut), the width of the console panes is forgotten, and the width of each pane is reset to an equal amount.

When resizing the console up/down using the mouse the widths are remembered.

Similarly, widths are forgotten when hiding or showing the left side bar.

Finally, widths are forgotten when adding or removing a pane - although this is the most understandable.

Hope this helps!

[Tyriar]

@jamesjryan there was an issue fixed in latest insider for the first 2 you mention https://github.com/Microsoft/vscode/issues/45074

Similarly, widths are forgotten when hiding or showing the left side bar.

I can't repro on latest, please create an issue if you're seeing it.

Finally, widths are forgotten when adding or removing a pane - although this is the most understandable.

Yeah this is as designed 🙂

[KillyMXI]

Someone is writing about split terminal, not terminal tabs here again. That's not what we'd like to see when getting notifications from this ticket :(

7504

[jamesjryan]

@Tyriar updated - works as described, thanks!

@KillyMXI it's progress towards the end goal, and a very useful implementation even in its current form.

[Tyriar]

@isidorn I'm wondering if you've given any thought into how we would initially support something like this. When I added tabs in the terminal just after the terminal was added I needed to revert because everyone was against having tabs in tabs, what if we made the panel headings tabs something like this:

I don't really know how to handle the sometimes large titles and need to say terminal here to disambiguate it from the others. Having said that, this would be my typical setup with (two tabs, one of which has a split) and it easily fits on my laptop screen when maximized, even without hiding the other panel titles.

I think the end game is giving the user the flexibility to put terminals where ever they want, but perhaps this is a good stopgap solution?

[KillyMXI]

@jamesjryan I can't see the Tyriar's solution as the progress towards the tabs. Looks completely orthogonal thing to me.

There are a lot of useful things around, but they have proper places. Proper place for split terminal is a different ticket.

[KillyMXI]

Finally we back to tabs.

Similar thing was proposed above, actually: https://github.com/Microsoft/vscode/issues/10546#issuecomment-359632932
That's the most obvious thing when replacing dropdown with the list of terminals.

I would've tried to

• align terminal tabs to the right;
• or add a vertical line before terminals;
• or align to the right and show a vertical line when they got close to the items on the left.

I'd rather avoid putting the word "Terminal" on every tab. It will be clear enough what it is.
Or maybe use the word "Terminals:" as a kind of a visual separator.

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

[JoshAntBrown]

So this is kind of the end result I would hope for here:

Taken from https://atom.io/packages/terminal-tab

It's simple and easy to understand and gives the flexibility to the end user as to how they want to split/structure their IDE.

[andrejarboe]

I'm confused. We can already have one terminal at the bottom, right, left, or full screen.

[batjko]

We can already have one terminal at the bottom, right, left, or full screen.

We do? How do I create a terminal on the left side? Right now, I can only see bottom or right side.

[andrejarboe]

You can't do left but still, I'm confused by this gif. lol

[JoshAntBrown]

I'm not sure about the Atom plugin (can't say I've used it), but I would assume you could open multiple terminals, they would all be treated as individual tabs.

Most importantly they behave the same as normal editor tabs do, they can go in the same places as you have your code. The web IDE Cloud9 does a very similar thing to this. You can open as many terminals as you want, and you're free to place them where you wish on your workspace inside the splitscreen+tabs layout.

[costincaraivan]

Maybe I'm misunderstanding the concern, but basically the UX designers are worried about confusion between different kinds of tabs.

I'd just hide the tab bar by default and have 1 "tab" visible. Keep the drop down thing.

Then once a new terminal is launched, if an option is set by the user, get rid of the dropdown and show a tab bar.

Am I missing something?

[itaysk]

I think it would be best to make the terminal a tab just like other editor tabs, and just let the user decide how they want to lay out the windows.

This is what the "confusing" gif above tries to demonstrate.

[JoshAntBrown]

Yes, sorry if the gif made it more confusing but this is basically the premise I was trying to get to.

On the point around UX designers being worried about confusion, I think if you're opening a terminal then you probably know what you're doing and it's not confusing at all.

[vedmant]

As some kind of workaround I set up following keyboard shortcuts:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

It lets me switch fast between terminals without need to use mouse and that ugly selector.

[Tyriar]

@vedmant you can refine that to only work when the terminal is focused if that's preferable too:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

[ldsands]

Sorry if something like this has already been suggested (I only skimmed the comments) or maybe I should make this into a new issue. Either way, let me know.

Given the progress that has been made with issue #14909. Could we have an option to put the terminal into a normal tab that is treated from a location standpoint the same as any other tab? This would give a ton of flexibility to users about how they want to view their terminal. There is now (or rather soon) so much flexibility with how to view and arrange normal tabs the terminal is now very limited by comparison.

[caub]

@Tyriar workbench.action.terminal.focusPrevious doesn't seem to be working

I also tried workbench.action.terminal.focusPreviousPane since it's how Defaults Kebindings use it, but it doesn't work (workbench.action.terminal.focuNextPane doesn't work as well)

so in short: only workbench.action.terminal.focusNext works

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

VSCode versions

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

OS: lubuntu 18.04

Tested without extensions

Edit

Thanks Tyriar, I wrote cmd instead of ctrl above

[Tyriar]

@caub you should create a new issue if you want help (it has always worked fine for me on Ubuntu 18 though).

[wmertens]

Recently realized a problem with having the terminal where it is: it makes it impossible to see the problems tab at the same time.

[caub]

I guess you've a workspace with multiple projects. What you can do, is to have one terminal per project, and have an extension focus the corresponding terminal based on the focused file in editor (and on which project it belongs to)

It doesn't solve your particular problem, but make it easier to switch and notice problems

I agree that the terminal select is really not practical, there are just numbers: 1: bash, 2: bash, .. it would be much better to show the folder basename rather

[Tyriar]

@caub see https://github.com/Microsoft/vscode/issues/29816

[caub]

With more practice, I realize this Tabs proposal is the best way :+1: , currently I still use my own OS terminals indenpendantly of VSCode, because the terminals select makes it not practical, even with better namings it would still not be practical enough

[mrmckeb]

I also think this could be nicely resolved if the terminal could live as a part of the grid layout, and would make a lot more sense from a UX perspective - where everything can be snapped anywhere.

[costincaraivan]

@mrmckeb Agreed. I'm not sure how they could handle both tabs and splits, but it's doable. Tmux does it.

I hope we get to dock terminals also in the text editor panes, that would be very flexible, already.

[sagebind]

I've been watching this issue for quite some time and still hoping for this to get implemented. I see that similar issues are opened somewhat regularly. Hopefully I can recap what exactly is being asked for and why (at least from my perspective).

What

Basically what I am hoping for is that a new terminal may _optionally_ be created as an _editor tab_, basically replicating the behavior of this Atom extension (which I have dearly missed since switching from Atom to VSCode). When a new terminal tab is created, it is treated in the same way as an editor tab and is placed in an editor group. Terminal tabs are treated in the UI identically to editor tabs.

Terminal tabs do not need to be interchangeable with terminals in the panel to start; they could be created as totally separate entities initially to gather feedback.

Why

I practically live in the terminal, and having terminal tabs in this way solves all of the following problems and use cases:

• See and use more than two terminals simultaneously. Easily done by arranging three or more terminals however I like on the editor grid.
• Use VSCode as my only terminal emulator, by opening a VSCode window with only a terminal tab in it.
• Have many terminals open at the same time, but I do not want to look at right now.

Even in a world of terminal tabs, I would find the existence of the panel as distinct from editor groups to be useful and I would not advocate for dispensing of the panel. The panel makes sense to place ancillary information distinct from the _primary content_ I'm working with. The key is that, to me, a terminal is usually _first-class content_ I am working with, and not merely ancillary content. With this perspective, it is completely natural for terminals to live together with editors.

[Tyriar]

@sagebind I see the first step towards this as enabling terminal tabs within the panel, essentially just swapping out the dropdown with something less horrible. This could then be built on in the following ways:

1. Allow the panel to be placed more flexibly https://github.com/Microsoft/vscode/issues/57029, https://github.com/Microsoft/vscode/issues/50984, https://github.com/Microsoft/vscode/issues/37877, https://github.com/Microsoft/vscode/issues/10121
2. Investigate allowing individual terminals to "detach" from the panel and be placed in the editor grid as you're talking about (kind of tracked in this issue). This needs a bit of work to figure out the impacts on UX, commands, keybindings and the extension API.

[jackjwilliams]

Also, @sagebind, not sure if you've ever heard of ConEmu, but it does what you described.

And if you're an old school gamer, it has a quake style drop down (Ctrl + ~). So all my termals stay hidden, until it's go time.

[PauloDanielCarneiro]

I think this extension shows how make tabs in a clean way.

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

[nzec]

@PauloDanielCarneiro That Extension is actually made by one of the senior developers of VSCode itself (@Tyriar)

[barretojs]

i know this issue is old, but this would be amazing

[fullenw1]

That's exactly the missing feature which prevents all SysAdmins to completely jump from ISE to VSCode.

As a SysAdmin I spend most of my time working simultaneously on several computers.

I connect to a remote computer with CTRL + SHIFT + R.
This opens a new terminal tab named with the computername to which I am connected.
And every terminal tab is linked to one or several script tabs below.
I switch from the script tabs to the terminal tab and vice-versa with CTRL + R.

That's so easy, handy and powerful at the same time...

[smshuja]

Is this feature being considered?

[Hum4n01d]

Not a replacement, but you can use cmd-\ to split your terminal

[smshuja]

Thanks @Hum4n01d thats even better, didn't know about that.

[lucasbasquerotto]

@Hum4n01d In my case I can split the terminal with Ctrl+], or just clicking the icon to split the terminal in the top right corner of the terminal window, next to the Kill Terminal option.

If I only need 2 or 3 terminals, I consider this feature very useful (even better than tabs, because I don't need to switch from a tab to another to see the terminal).

Only in the case in which I need several terminals this might not be a solution, although tabs also might not be (per se), instead it would need something like tabs + floating windows (https://github.com/Microsoft/vscode/issues/10121).

[mrmckeb]

I still believe the best approach here is the one that the Atom team went with, having terminals interchangeable with code tabs. This way, users can create the workspace they want in a modular way.

Tabs in the terminal area would be cool, but why invest in doing that when the time could be spent allowing code tabs to wrap terminal instances?

[Yzrsah]

Hello. I went searching about an issue I am having and I ended up here.

The only thing I want to do is to use a Terminal as a regular editor tab

My 15" laptop display is just not big enough to mess around with the little terminals crammed into a build output section panel. It works fine for builds, but it can be inappropriate for terminal use.

If I resize the Panel to be large so that I can do actual work there, suddenly it makes no sense for the build output popup to become super large. And if I make it small so that it's appropriate for build output, then it's unusable for terminal work. These UI concepts do not mix together and adding in Tab bar there is further insanity.

And what if I literally don't want the job I am doing in a terminal to be a part of a panel that is switching between tabs when I execute tasks? Or popping up and down dynamically? So that every time I build, now I am switching the tabs in some other tab system? And then switching back to the stuff I was working on in the terminal? Oh, so the solution is that we can Split the Panel... This gets crazier, and you have a reproduction of the same UI system that VSCode already has. It does not make sense.

It would be a bad idea to turn the Panel into a parallel UI system with competing idioms. Various people are trying to do this with poor hacks and workarounds in extensions. So it would be good if Microsoft took control over the situation by fixing the issue.

[shane-smith]

@Zyrsha - in that case, why are you using VS Code? It sounds like you would get more value out of directly using the actual terminal that comes with your operating system, with multiple tabs. Honest question / very confused reader.

[Bessonov]

BTW vscode is the first and only IDE where I use terminal in it. On my 13" laptop it works fine for me. For other IDEs like eclipse or webstorm I'm very happy to use Awesome WM for fast switch and window ordering.

I think the idea to use terminal (or any other "window") as a regular tab is nice and it works in eclipse. But terminal has a slightly different workflow, at least for me. I need a possibility to switch fast to the "right" terminal. Like others I use Terminal Tabs for that:

which is, unfortunately, not perfect because of issues like this one. Moreover, I don't understand why vsc shouldn't have a sophisticated terminal built-in.

[sagebind]

@shane-smith

the actual terminal that comes with your operating system, with multiple tabs.

Well the Console application that comes with Windows doesn't have tab support AFAIK. So that's out. And Linux doesn't "come with" a terminal emulator per se (a distro might), you have to pick one you like. In this case it seems the one @Zyrsha likes is VS Code, if it can be improved a little bit.

[shane-smith]

@sagebind

In this case it seems the one @Zyrsha likes is VS Code, if it can be improved a little bit.

Oh, I agree - the terminal in VS Code is awesome. And I'm commenting on this issue because I agree that it has some room for improvement.

The part I'm confused about is that it seems like the other person wants to use the terminal to edit all of their files - so I'm wondering why they would use VS Code, if they aren't actually using the built-in file editor at all? Re-reading their comment, perhaps I jumped to conclusions and they only want to edit _some_ files in terminal, not all of them.

[ecanuto]

Hello.

The part I'm confused about is that it seems like the other person wants to use the terminal to edit all of their files - so I'm wondering why they would use VS Code, if they aren't actually using the built-in file editor at all? Re-reading their comment, perhaps I jumped to conclusions and they only want to edit _some_ files in terminal, not all of them.

No, they just want to have terminal tab like editor tabs, exactly what we have on Cloud9, Atom and some other editors (even Vim and Emacs). For people that uses Mac or Linux, it is natural to have editors at upside of the window and some terminal tabs at bottom.

Even Theia-IDE can have multiple terminal tabs and it is based on some parts of VSCode.

Take a look at this screenshots and you will understand:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

[wmertens]

Ok, let's ignore the why for a moment and focus on the how:

How would this be implemented? Is there an architectural reason why terminals are in their current location?

Would it be possible in an efficient way to have a plugin provide terminals in tabs?

[fullenw1]

      Ok, let's ignore the why for a moment and focus on the how:

How would this be implemented? Is there an architectural reason why terminals are in their current location?
Would it be possible in an efficient way to have a plugin provide terminals in tabs?

On the architectural side:

• VSCode has many scripting tabs linked to one single console (PowerShell integrated console) which is very good for testing several scripts on one single machine. However, even when you add more terminals all scripting tabs remain linked to the same PowerShell integrated console.
  At the beginning, VSCode has been writen by developpers for developpers.

• ISE has been build the opposite way: you can open multiple console and to each console you can link multiple scripting tabs (this is very good for working simultaneaously on multiple computers).
  We write and run simultaneously multiple scripts on different computers.
  At the beginning, ISE has been designed for SysAdmins.

Fortunatelly, the ISE way (Scripting tabs linked to Console tabs) works for developpers too.
But the current VSCode way (Console tabs linked to "one single" Scripting tab) doesn't fit for SysAdmins.
If you don't want to or cannot reverse the way (from Scripts linked to Consoles toward Consoles linked to scripts) at least we should be able to choose to which console tab we want to link each scripting tab...

[jaxspades]

I don't know anything about ISE, but I definitely want to be able to have the terminal in its own tab or window, rather than permanently attached to the bottom of the screen. I don't like having to adjust the height to switch back and forth from code files to a terminal.

Also, while terminal tabs _does_ solve the issue of wanting more than one terminal active, from a UX standpoint, it would still be better to have terminals in the same tabs that are used for files. This ensures that you have two standard keybindings for switching tabs, rather than two standard, and two for Terminal Tabs (not including the numeric keybindings for switching to a specific terminal tab). The workflow for splitting the editor using those tabs, or moving tabs to other VS Code windows, or whatever else you can do with tabs, would then be the same, and would create a standard UX. As it stands now, you have two different UX workflows, and you do not gain much from having the two.

I understand why it might not have been done until this point, or why we have Terminal Tabs as a workaround, but terminals in editor tabs/buffers/whatever is being done across the board in Emacs, Atom, and the like, as a standard UX experience, that I would also love to see in VS Code.

[floydnoel]

Now that Nuclide is deprecated, I'd like to switch to VS Code, but I really like to be able to read all the build output on the terminal- which is very difficult with VS Code. Why does the terminal need to be forced into a specific spot, and not treated the same as every other tab/window?

[dustypomerleau]

For me, the primary issue is that I can't see how many terminals I have open without going for the mouse. And there is no way to know which direction you should head to get to a particular terminal without arbitrarily cycling. Tabs were my first thought, but I suppose there are other ways to solve this problem. You could, for example, optionally show active terminals in the Explorer bar, with the active terminal highlighted.

[mk-pmb]

How would this be implemented?

For linux, we could implement it as just a special case of a more general approach: Run user defined commands and provide them with an X window identifier of the new tab. We could then run xterm … -into $VSCODE_TAB … for the terminal, but also integrate other stuff very easy. Would also be nice if there was a CLI command to search for a VSCode instance by project directory (default to working directory of where the command was run), open a tab in that instance, and print the X win id on stdout and VSCode's $DISPLAY if different so any external utils could join VSCode's GUI.

Edit 2: I'll open a new ticket for that idea since it's not really about terminals.

[dhonx]

no !!! tab make ui look bad....

[mk-pmb]

@donnisnoni95

no !!! tab make ui look bad....

I'm very optimistic it will be easy to deactivate and/or hide them.

[andraz]

Simply convert the drop-down to buttons and style them same as tabs of the main editor.

[floydnoel]

Just to be clear, I would want the tabs to be interchangeable with all the other tabs (e.g. the source code tabs). Just like it is in Atom.

[kitsirota]

Just to be clear, I will take either @andraz's or @floydnoel's solutions given that the OPs request has gone unnoticed since 2016

[jaxspades]

@kitsirota It has been noticed, and is on this year's roadmap. They know that this, and a related issue for floating windows, are the two most requested features. I'm not sure when it will be started or complete, but maybe @Tyriar has more info on that.

[Tyriar]

I expect this will get some attention soon because of the demand, I really want it too. Also as @jaxspades mentioned it's on the roadmap.

[gagle]

Waiting for this and floating windows from the first day I started using VSCode. Currently I'm using ConEmu. It's just not handy the current attatched and dropdowned terminal.

[mikemaccana]

Just a note (while tabs should definitely be added to vscode) if you're still using ConEmu you may want to try Windows Terminal.

[kulttuuri]

Still waiting for this :)

[FoldZero]

I would just like to see "Output" & "Debug Console" at the same time.

[ggedde]

I don't necessarily need tabs, but I want to see Problems and Terminal at the same time. However, it might be hard to differentiate them apart without some sort of label and therefore a tab might be best. So I think the split panel for terminal should be removed and allow for additional tabs for all panel types (Problems, Output, Terminal, etc) Although I can't really see how multiple "Output" or "Problem" tabs would be needed as the data would be identical. So maybe when adding a new tab and selecting which type your adding, if Problems is already open then it is greyed out and disabled from adding a second one and only Terminal is allowed for multiple. Also clicking on the Problems and Warnings indicator in the status bar should auto open a new Problems tab when clicking on it and if it is already opened then it removes it.

[mk-pmb]

Although I can't really see how multiple "Output" or "Problem" tabs would be needed as the data would be identical.

• Creative multi-user constellations beyond classical 1:1 mapping of screens/keyboards/input focii to users.
• Single user distributing the tools used for problem solving accross multiple screens or screen regions. In which case it would be useful to have filter settings, scroll position etc. independent for each Problems/Output panel.
• Working around exotic bugs/missing features in your screencasting software.

[Bessonov]

@Tyriar @jaxspades are 1754 :+1: and 187 :heart: not enough? And 34 :rocket:? How much it should be?

[avatsaev]

This is still open?!

[mk-pmb]

Would it help to crowdfund this? Where do I put my money?

[jaxspades]

@Bessonov I want terminal tabs but I'm not at Microsoft so I have no say. I want them as an editor though, not in that tiny window at the bottom of the screen. So version 1.43 just shipped with Search Editors, so my hope is that Terminals will soon follow. @Tyriar, does Search Editors help us get closer to Terminal Tabs/Editors?

Edit: Adding a link to the Search Editors issue.

23931

[Tyriar]

Again, this is on the roadmap, it will happen in time. You don't need to tell me, I likely want it more than everyone here and am well aware that it's the 2nd most voted issue. However, it's not as trivial a task as it may seem on the surface. We are actively investing into flexible workbench layout:

• Search in the panel
• Search in the editor
• All panel and viewlet views being interchangeable

All these efforts are feeding into how this issue will eventually be resolved and are largely blocking the work on the terminal, for example the design we're considering for the latter item is bringing up some very important questions about how tabs in the terminal will work as opposed to panel views.

I want them as an editor though, not in that tiny window at the bottom of the screen.

While I tried to separate the concepts into separate issues a long time ago, this issue covers a few things now; tabs within the terminal panel, terminal tabs in the editor and terminal tabs being draggable between the two.

[mrmckeb]

Thanks for the updates @Tyriar. That sounds great - solving all of these issues together makes a lot of sense. If there are any opportunities for user testing, do let us know.

[fullenw1]

Not sure this idea has been mentioned, though I've been gone through the whole comments:
We (also) need terminal tabs not because of the look, but because currently all editor tabs are linked to the same terminal.

Currently, if I want to output the run of editors in another terminal I have to open a new VS Code console.

Beeing able to link an editor pane to another terminal is especially useful when you want to execute the code of different editor panes against different computers. With ISE you can do this in the same console.
Currently with VS Code, you have to open as many consoles as computers on which you want to execute you editor's code.

[ggedde]

@Tyriar ,
Along with your notes I would also like to be able to see "Problems" and a "Terminal" window at the same time side by side. I hope that is also possible.
Thanks

[Tyriar]

@fullenw1 interesting idea I hadn't heard of yet, thanks!

@ggedde we're actively discussing how this would work in UX meetings.

[vitorpiovezam]

With the issue #10121 solved this will be more than never a good feature.

[dillingham]

The terminal panels need a heading of some kind..

It's impossible to know which panel is what path when you have multiple watchers on

[dillingham]

@IceSentry I did have an issue but @Tyriar said it was a duplicate of this one. I assumed it was related because @Tyriar closed mine in favor of this.. no I didn't read 6 years worth of dialogue :)

[stuartpb]

I don't know if anyone's pointed this out yet, but Terminal tabs that are interchangeable in the UI with Editor tabs, as well as a fixed UI console, are both features in the Cloud9 IDE, if you want an example of how I'd expect this to work. You don't even need to get rid of the old Terminal pane - just have it able to be hidden (as it is now) and replaceable with an ordinary "editor" pane containing Terminal tabs.

Another nice thing about Terminals in Cloud9 was that they attached to (IIRC) tmux instances rather than direct terminals. This allowed the frontend to rescale (ie. shut down) without losing terminal processes, and to smoothly attach to a new client (a feature which would be very useful for cloud VS Code users), and even share client terminal instances with other (hypervisor-level) users.

There are extensions to do this for the built-in VS Code Terminal, but if you're looking for an abstraction for terminals, it'd be cool to bundle in dtach or abduco.

[tobia]

Terminal tabs that are interchangeable in the UI with Editor tabs

This is just brilliant.

We could get rid of the bottom console and turn all of its panes (Problems, Output, Debug console, and all of the terminals) into regular editor tabs, that can be opened as needed, each pane type having a specific icon.

As a reference, the Extension information pages, Settings UI, Keyboard Shorcuts, and probably other things are already handled in this way, as regular editor tabs with a custom icon.

This would allow people to split and arrange their terminals as they please, using the existing features for splitting and arranging editor tabs.

Of course terminals should keep running in the background even after closing the respective editor tab, which could be reopened as needed. The additional suggestion to use tmux or dtach to keep the terminal session running across VSCode restarts is also a great idea, but belongs to a different issue.

[mmis1000]

With the new webview api, we probably already can do it to some point.
But that means you need to write all launch.json handling by your own, which is not ideal.

However, there is a benefit to make it just an editor 'tab', because editor tab can have Serialize/Deserialize handlers.
Thus is is possible to give terminal the saving and restore behavior. (like, save the tmux session id and reattach on restore)

POC: https://github.com/mmis1000/Vscode-terminal-tab

[Tyriar]

@mmis1000 it's certainly possible to build with the webview API now, but it will be missing all integration, commands, features like link handling, extension api access and will just act like a separate thing generally.

The save and restore feature is tracked in https://github.com/microsoft/vscode/issues/20013

[mmis1000]

@Tyriar I actually though of spawn a Terminal instance instead and use it as the underling pty instance, so at least things like git integration will work (looks like it need to pass some env to the terminal).

However, it turns out the api vscode exposed is way too limited. Not only it did not expose the underling pty process, it did not expose stdio and terminal functions like pty resize either. Makes it totally impossible to be used as a pty source. So I was forced to spawn the pty on my own.

[Dimfred]

POC: https://github.com/mmis1000/Vscode-terminal-tab

Hey @mmis1000 could you maybe add some install instructions, that would be great. Would really like to have this.

[Tyriar]

@mmis1000 it's limited by design as this should be part of the core product, there are also performance problems with the window.onDidWriteTerminalData event which is why it's stuck in proposed. While this sort of extension could be useful as a temporary solution, I worry about the potential long tail of users once we get terminals to work within the editor area. Another problem you could end up hitting is reliance on node-pty shipped as part of vscode, this is not public API intended for consumption and will likely break your extension in the future.

[mmis1000]

@Tyriar As a cloud9 user (and still be a cloud9 user now).

It is kinda helpful to just use any screen area as a terminal and with session persistent backed by tmux.

I mostly just use cloud9 as a web terminal to control the VPS. (And this is the ONLY reason I still use it now. Becuase vscode really done poorly about the terminal. It is a giant pain to lost the terminal by accident reopen it every time).

Cloud9 just always show the same window, same editor, same terminal and the same session at same place as you see before you close the browser yesterday. If it isn't able to find the session (maybe the server rebooted), it will at least reopen a new one with same environment for you.

If I am about the use another online editor service (I mean, open in the browser), I kinda will expect it to support these out of box (or at least achievable by extension), because you are unlikely not to close your browser (by intentional or by accident) at all.

(Also because cloud9 did this years ago, so I don't really feel this is a technical problem)

The terminal experience vscode provided doesn't really look a latest gen product to me to be honest.

[educbraga]

@mmis1000 Could you please add some install instructions?

[mk-pmb]

The https://github.com/mmis1000/Vscode-terminal-tab repo has its own issue tracker. Anyone who feels the need to ask about that project, please ask there.

[mmis1000]

For a demonstration about what terminal I am expect to see on a remote ide / browser based ide.
I would expect it to just restore the tab position / terminal session as I close it yesterday.
Instead of It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD.

[xgdgsc]

That' s another issue https://github.com/microsoft/vscode-remote-release/issues/3096 .

[mmis1000]

@xgdgsc looks likely but isn't.

What I expect is that is terminal persistent available universally even on local vscode instance. (at least to the point iterm2 does)
Why such a useful function need to be limit to remote connection?

And I didn't persistent the ssh connection either, I just hook up some terminal multiplexer and run things there.

[Tyriar]

@mmis1000 again that's tracked in https://github.com/microsoft/vscode/issues/20013, see there for the latest. Try keep on topic as there are _a lot_ of people who get notified when you comment on this issue.

[xsoheilalizadeh]

Is there any chance to have this in the following iterations?

[yulei900609]

Open terminal as a normal editor page tab is a wonderful idea for me, and i need this very much.