Tabs for integrated terminal

[Perkovec]

Status update from @Tyriar:

• We started exploring this in March Tabs for integrated terminal #10546 (comment)
• April plan: Terminal tabs April plan #120241
• Tabs have landed in Insiders work in progress & call for feedback Tabs for integrated terminal #10546 (comment)
• Moved to backlog to cover terminals in editor area Tabs for integrated terminal #10546 (comment)
• Assigned to June for "terminal editors" Tabs for integrated terminal #10546 (comment)
• Terminal editors plan filled in (Terminal editors June plan #125514), request for feedback Tabs for integrated terminal #10546 (comment)

---

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: #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 #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 😮 this is using the new terminal API? That's awesome!

[wclr]

@Tyriar Yeah, that one you are working on 😉

[nk-dm]

@Tyriar

• Click the bin icon n times, we keep the tabs open now even when there is a single tab to make this easier

This would be easier if ongoing processes weren't marked with a moving circle thingy that pushes the bin icon to the left(making the not aligned).

• We're bringing back the panel bin icon so hit that n times.

Good idea, looking forward to that.

[sagebind]

I know its been a long time to get here, and I know this is still in development, but after playing around with the latest Insiders I feel the need to give some early credit to where its due: It's so beautiful!

This is basically exactly what I've always wanted, glad to see its coming along nicely! 👍 I look forward to a noticeable improvement to my workflow once released. In Insiders there's a few things not implemented yet and there's a bug or two, but overall its already quite useable.

The bug I ran into was this: I was creating, rearranging, and destroying a bunch of terminals (as you do) and at one point when I tried to close a terminal editor I got an error instead (from the console) and the tab went blank:

[2021-06-24 13:40:45.631] [renderer1] [error] Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.: Error: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

Stack trace

  at e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm-addon-webgl/lib/xterm-addon-webgl.js:1:18970)
  at Object.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:143534)
  at t.e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:219708)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:146376)
  at t.e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:219708)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:173034)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:43060)
  at e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:307866)
  at fi.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2718:85163)
  at vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1521:38328
  at Object.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12535)
  at C (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12257)
  at h.clear (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12717)
  at h.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12696)
  at k.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:13231)
  at k.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1503:57284)
  at Ii.handleOnDidCloseEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:10701)
  at vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:9622
  at r.fire (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:60:1835)
  at ki.closeEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1503:86730)
  at Ii.doCloseActiveEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19701)
  at Ii.doCloseEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19289)
  at Ii.doCloseEditorWithDirtyHandling (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19140)
  at async Ii.closeEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:18969)
  at async O.runAction (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:171:30929)
  at async O.run (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:171:30829)

I haven't been able to reproduce it though.

[Tyriar]

This would be easier if ongoing processes weren't marked with a moving circle thingy that pushes the bin icon to the left(making the not aligned).

@nk-dm this is how we render decorations everywhere so I don't think we would be able to change that behavior. An alternative is to use delete while in the tree.

---

@sagebind awesome! We keep a very up to date list of bugs and remaining work in this query, some fixes will be in main but not released for a day though (or more over weekend). There are still some annoying ones we're tracking down related to the panel showing when no terminals are there and reconnecting not working consistently.

[ardunster]

I'm looking forward to this as I recently ended up with a workflow where I need three different terminal tabs (and I keep them open/split) and having them a) repopulate in a random order when I reload the window and b) not be able to drag and drop them to rearrange them is driving me nuts.

[Tyriar]

@ardunster the random order one is tracked in #127090, drag and drop will be fixed in tomorrow's build

[Tyriar]

Ok I think it's time to call this done! We'll likely spend part of next iteration adding some final polish touches to tabs but the core feature is finished and it's pretty reliable at this point (we'll see how testing goes next week).

We're tracking remaining issues against these labels: terminal-editors, terminal-tabs

Thanks everyone for all the input in making these features come to life ❤️

[g3offrey]

Hello,

First of all I want to thank you @meganrogge and @Tyriar about the awesome job on terminal editors. This is literally a game changer for me 😍

I tried this feature a lot these last days, and I encountered an issue that I think is not mentioned here.
When I close terminal editors, they are not deleted from the listing when typing term in CMD+P palette.

I share you a gif that shows this issue.

Steps to reproduce :

1. Open clean and up-to-date "Code Insiders" instance
2. Create a bunch of terminal editors (either via command palette or drag and drop)
3. Close them using the bin / closing the editor or via "kill" command
4. Open CMD+P palette and type term
5. ⚠️ Closed terminal still appears here

If I can help you on this issue, don't hesitate to reach me.

Again, thank you for your work on this feature. ✌️

[Tyriar]

@g3offrey great find! This is one of the lesser used features so happy you spotted it, created #127307

[g3offrey]

Hi @Tyriar, @meganrogge

Thank you for the work on terminal editors, day after day the experience is more and more polished. ☺️

Today playing with the latest insiders I encountered a weird bug.

Playing with splitted editors, one terminal on the left and one on the right and using the term listing panel to switch from one to another, the terminal is completely broken.
I'm sorry that I am unable to do a screenshot at the moment (no laptop).

Steps to reproduce :

Open latest insiders
Create new terminal editor
Split it using editor split button on top right.
Switch from one terminal to the other (several times) using CMD+P term listing.
I hope that my message is clear enough. If not don't hesitate to tell me, and I'll do a video for you on Monday.

[meganrogge]

@g3offrey yes I can reproduce that. very strange, thanks. will investigate

[wenfangdu]

@Tyriar Could you consider exposing terminalTabsSingularSelection as a public context key?

[sonhanguyen]

Great feature!

I have a feedback though: could we consider making the tab list floating on top instead of taking space in the layout? And maybe not taking the entire height? The right side of the terminal is almost always blank and we could also make it only shows icon and reveals when hover. The current terminal tab list is kind of wasteful especially for people like myself who mount the panel right instead of bottom.

[Tyriar]

@sonhanguyen the current solutions for that problem are to use the narrow view or disable tabs:

[Tyriar]

@wenfangdu based on your usage above I don't think you need it, you just needed the exception fixed. Generally internal/complex context keys like that are not encouraged for use as they clutter the code/docs/autocomplete and makes changing them harder.

[wenfangdu]

@Tyriar Thanks, per your suggestion, I changed workbench.action.terminal.joinInstance's when condition to terminalProcessSupported && terminalTabsFocus.

[joenoon]

Editor Terminals are great, thank you! The only issue I've run into so far is:

• Open a couple files and editor terminals
• Make an edit to any open file without saving
• Right click on any open editor tab > click "Close Saved"

This will close all saved files and leave unsaved files (as always), but also closes all editor terminals.

I would think editor terminals would be by definition always "unsaved", remaining around after "Close Saved".

[Tyriar]

@joenoon in insiders terminal editors now are marked as dirty (need saving) when they have subprocesses, this can be disabled with the terminal.integrated.confirmOnKill setting. We're also investigating making terminal editors a little more sticky in #124709

[mmis1000]

Is it possible to keep editor terminal in place after restart the vscode?
(It's fine that the process gone and just the terminal editor keeping in place)

[Tyriar]

@mmis1000 the only way to do this right now is by using tasks when default location is set to terminal (eg. auto run on window open or ctrl/cmd+shift+b)

[mmis1000]

Besides that, will there be extension APIs for manipulating editor terminals?
For example: events of getting created/merged back, query the positions or method for open it in specific place.

(Probably not a target at all now because even the editor terminal isn't completely stabilized yet. Just ask out for curiosity)

[Tyriar]

@mmis1000 we'll explore some of that in #45407