Tabs for integrated terminal

[Perkovec]

Status update from @Tyriar:

• We started exploring this in March https://github.com/microsoft/vscode/issues/10546#issuecomment-800286034
• April plan: https://github.com/microsoft/vscode/issues/120241
• Tabs have landed in Insiders work in progress & call for feedback https://github.com/microsoft/vscode/issues/10546#issuecomment-823291688
• Moved to backlog to cover terminals in editor area https://github.com/microsoft/vscode/issues/10546#issuecomment-826900427
• Assigned to June for "terminal editors" https://github.com/microsoft/vscode/issues/10546#issuecomment-852971002
• Terminal editors plan filled in (https://github.com/microsoft/vscode/issues/125514), request for feedback https://github.com/microsoft/vscode/issues/10546#issuecomment-860644971

---

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.

[wclr]

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.

[wclr]

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.

[wclr]

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!

[wclr]

@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

[wclr]

@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?

[wclr]

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

[wclr]

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.