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

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

[jshbrntt]

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

[mlcloudsec]

+1

[amc123-glitch]

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.

[amc123-glitch]

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

[amc123-glitch]

@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

[amc123-glitch]

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