Terminal: Feature Request: Start with multiple tabs open

[afalk42]

When editing the profiles.json settings file, it is currently not possible to specify more than one defaultProfile. As a result, it is not possible to have the Terminal automatically start up with more than one tab. It would be extremely convenient, to be able to specify the 3 or 4 most commonly used command-line environments to all open up in separate tabs every time Terminal is started. This would e.g. give users the ability to always open up a Command Prompt, PowerShell, and Ubuntu shell all at the same time.

[DHowett-MSFT]

I'll repurpose this one to be the main feature request tracker for starting with multiple tabs.

[mdtauk]

If this is more of a niche issue, perhaps there could be a json file in a folder to enter a list of profiles to load on startup? Or perhaps it could remember the last session before the app was closed?

[afalk42]

@mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab

[mdtauk]

@mdtauk there is already the ability to add multiple profiles to the profiles.json configuration file, but you can currently only specify one of them as your defaultProfile, which is why you can only start with one tab

Yes I am aware of the profiles.json, and I am sure that will get a GUI in the settings for the app soon.

But you could change defaultProfile to have a list of profiles I suppose.

Maybe in the GUI there could be an option in each profile's customisation page:

[✔] Include this profile when starting Windows Terminal

[Kryptos-FR]

I'd rather have those settings spit into two different files: profiles.json is portable between machine (and maybe users), while the default(s) could be user dependent (so defaultProfiles.json?).

[zadjii-msft]

Lets try to reel things in before the discussion gets out of hand - a couple things mentioned here deserve their own threads to discuss them.

perhaps it could remember the last session before the app was closed?

This is now #766

I'd rather have those settings spit into two different files: profiles.json is portable between machine (and maybe users), while the default(s) could be user dependent (so defaultProfiles.json?).

This is #641

I'm all for adding a setting for which tabs/panes & profiles to open with, though we'll probably need to keep "default profile" as a single profile GUID.

[glen-84]

I don't think that this is necessary if #766 is implemented. It would be more than covered by session resumption features.

There's only one small edge case that I can think of:

1. Open window 1 with the 3 profiles that you're interested in.
2. Open window 2 with another profile that isn't so important.
3. Instead of closing window 2 and then 1, or using the "Exit" option to close both windows, close window 1 and then window 2.
4. When the session is resumed, only window 2 would be restored.

However:

1. It's not something that would happen often.
2. If support is added for window history, window 1 could be reopened from "Recently closed windows".

@afalk42 Would #766 support your use case?

[afalk42]

Hi @glen-84
Yes, this would be sufficient for my narrow use case.
But think about the analogy with multi-tabbed web browsers for a moment: there we typically give users the choice of starting a new session either with a fixed list of tabs, or with the same tabs that were available when the browser was closed.
So in an ideal world I would love to see both #756 and #766 implemented.
But if time constraints only allow for one, then #766 appears to be more useful to more users due to simplicity of usage.

[WSLUser]

so in an ideal world I would love to see both #756 and #766 implemented.

I would second this. Whichever is the easier to tackle first should get out the door but the terminal is becoming a browser for CLI stuff basically (we have tabs just like an actual browser and can select different "websites" aka console apps) and thus needs to act as one accordingly.

[gregchamblin]

I would think the easiest way to implement this, and feel free to correct me if I am thinking to simplistically here, is to make defaultProfile a list, and iterate over it. If that is one tab or twelve.

I could also see a usefulness instead of opening with multiple profiles, just make one Hotkey open multiple profiles. Then, I could setup multiple (hidden?) profiles for each project I am working on. To me, this method would be preferred.

[joe-mills]

I would like a higher level grouping like a terminal workspace that reflects the project I'm working on in VS Code e.g. I would open a tab for dotnet API, ubuntu Angular, dotnet STS server etc.
It seems like that's the kind of thing that could be developed as a Windows Terminal extension and installed from the terminal extension store.

[WSLUser]

@joe-mills that sounds like a separate feature request and would require Windows Terminal to implement an API similar to VS Code to enable extensions. This is doable but _effort_. I wouldn't even consider trying to implement that until we at least have a stable v1 out the door. You'd constantly be having to change the way the API behaves until everything is settled down enough to know, "this is our baseline".

[joe-mills]

@WSLUser yes I guess I was just agreeing that profile groups would be nice but thinking its probably too early to start adding these kind of quality of life features in before v1.

It seemed like the extensions community was a great proving ground for features in vscode and the terminal app does lend itself to some kind of extension management system. Really enjoying the terminal right now though.

[DHowett-MSFT]

So I suppose this was discussed before in #1043, though there doesn't seem like there's a unique issue for it, so congratulations, this is now the thread :)

There are probably a bunch of things we'd want to consider as part of a comprehensive solution here.

• What if someone wants to open the terminal with multiple tabs (what you've already discussed above)

• What about with multiple panes, in various different split configurations? How would we set that?

• Perhaps the user wants to auto-launch multiple _windows_? In different locations, etc.

• Obviously, any solution for the above three should not preclude any of the others. Users would want to be able to specify multiple windows, each with their own tabs, and with tabs that might have any number of panes.

• Would we want this multi-launch behavior to only happen on _first_ launch, or _every_ Terminal launch?

• With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that?

• (I'm sure there's more I'm missing here)

This is certainly a problem that's feasible from an engineering standpoint, but due to the complexity of specifying these scenarios, I'd want a spec written first to try and think through the edge cases before we start working on the code.

_from @zadjii-msft in https://github.com/microsoft/terminal/issues/3037#issuecomment-537940097_

[0c370t]

To throw in my two cents on the comment above, I found this thread looking for a way to launch 3 tabs in a single shortcut, while opening another with a separate shortcut. For my dev environment I need to have 3+ cli programs running [klink (kitty cli), iisexpress, and ngrok], and I've just configured these to each be separate tabs, it would be great if I could create a shortcut to open those three, and another to open my WSL tab, so I don't have to choose one or the other.

[Borkason]

@gregchamblin Yeah, this would suffice in my opinion.

Simply something like that:

• What if someone wants to open the terminal with multiple tabs (what you've already discussed above)
• What about with multiple panes, in various different split configurations? How would we set that?
• Perhaps the user wants to auto-launch multiple windows? In different locations, etc.
• Would we want this multi-launch behavior to only happen on first launch, or every Terminal launch?

I think that renaming the setting defaultProfile to defaultProfiles and have them accept a list of profiles should be the first thing to to. This should be a quick fix (said the amateur programmer 😛).

For bullet points two and three, I think we should move a few terms around. What today is considered a profile, I would rename to shell. Then I would use profiles to combine multiple shells. In a profile you could either define all of those things mentioned in the bullet points, or tell Terminal to open the last session.

The dropdown should be changed to display profiles, but also shells. Shells should be hidable from the list, in case they are only used in profiles.

• With the nesting behavior you have above, what if someone had a recursive loop, where one profile A specified launching profile B, and B specified launching A? That would theoretically cause an infinite loop - do we allow that?

With the quick concept I described above, this would not be possible as a shell is just the pure look and feel of exactly the described shell. You would not be able to nest a shell in a shell, that wouldn't make sense anymore. And profiles cannot be nested in themselves.

A quick example

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "defaultProfile": "{11111111111}",
    "globals": {
        "initalCols": 180,
        "initialRows": 30
    },
    "shells": [
        {
            "guid": "{...}",
            "hidden": false,
            "name": "cmd",
            "commandline": "cmd.exe"
        },
        {
            "guid": "{...}",
            "hidden": false,
            "name": "Ubuntu"
        },
        {
            "guid": "{...}",
            "hidden": true, // Only used in a profile.
            "name": "Ubuntu Dark Theme",
            "colorScheme": "Ubuntu Dark Theme"
        }
    ]
    "profiles": [
        {
            "guid": "{11111111111}",
            "name": "My default profile",
            // If *layout and openLastSession are used in the same profile, throw error
            "openLastSession": true
        },
        {
            // Opens one Terminal with multiple tabs
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu"
            ]
        },
        {
            // Opens one Terminal with multiple tabs. Layout:
            // ╔═══════╦═══╗
            // ║       ║   ║
            // ║       ╠═══╣
            // ║       ║   ║
            // ║       ║   ║
            // ╚═══════╩═══╝
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu",
                "Ubuntu Dark Theme"
            ]
            // If *layout and openLastSession are used in the same profile, throw error
            // Instead of tabLayout, windowLayout can be used to open multiple windows instead of tabs
            "tabLayout": {
                // In the tabLayout (windowLayout) the defined shells would be used in order.
                // shell:cmd
                "split": "vertical",
                "ratio": [70, 30]
                {
                    // shell:Ubuntu,Ubuntu Dark Theme
                    "split": horizontal,
                    "ratio": [40,70]
                }
            }
        },
        {
            // Opens one Terminal with multiple tabs. Layout:
            // ╔═════╦══╦══╗
            // ║     ║  ║  ║
            // ╚═════╩══╩══╝
            "guid": "{...}",
            "name": "Side by side"
            "shells": [
                "cmd",
                "Ubuntu",
                "Ubuntu Dark Theme"
            ]
            // If *layout and openLastSession are used in the same profile, throw error
            "tabLayout": {
                // In the tabLayout (windowLayout) the defined shells would be used in order.
                // shell:cmd,Ubuntu,Ubuntu Dark Theme
                "split": "vertical",
                // If less ratios are given than tabs,
                // the remaining width is spread equally to the remaining tabs.
                // In this case 60, 20, 20
                "ratio": [60]
            }
        }
    ],
    "schemes": [...],
    "keybindings": [...]
}

That's only a quick and rough idea.

• For the tabLayout and windowLayout I decided to define the shells only in the profile section, instead of in the tabLayout section. That way the shells always has the same place regardles of what you're configuring. It also allows for quick reordering shells while keeping the layout you defined.

[bormm]

I want to extend the "shell" and multiple profiles discussion with my use case:
I want to open multiple powershell core windows with only one difference: they should have a different startup directory. I don't think that the current structure of profiles that contain all settings are appropriate for that, because that would produce a lot of duplicated settings. Maybe they is some need for profile or shell inheritance, so the "pwsh - directory A" and "pwsh - directory B" can inherit from the "pwsh - default" profile/shell.

Of course that would be an other complex issue, but I wanted to mention such use case for multiple startup "profiles".

[zadjii-msft]

@bormm I think we're planning on using some derivative of the commandline args functionality described in #3495/#4023 to help enable this functionality. With the wt commandline, you'll be able to do something like wt new-tab -p pwsh -d path/A/ ; new-tab -p pwsh -d /another/path and open two tabs in path/A/ and /another/path. Does that sound like what you're looking for?

[bormm]

@zadjii-msft No, because I want be able to open a tab with this directory at any time also in a existing WT instance. But I was mentioned to that ticket, what would be match my requirements: #3818

[zadjii-msft]

Ah okay, yea that's the issue you should follow. I've been working on #607 for a while now, so maybe I'm a little prone to thinking that it'll solve everything 😝

[WSLUser]

Having more than one way to support a feature or subset of a feature can't be a bad thing. That just gives people choices. In some cases, the use of wt.exe may be good enough and easier to do. In other cases #3818 may be the better option in which your current work might help speed up the process of resolving.

[ladal1]

I have to agree with @WSLUser that more solutions are better, since @DHowett-MSFT forwarded me to the command-line args in my issue I have started using them, but it does feels more like a good hack around the problem, rather then a full solution. You lose a some comforts that terminal has (live tile in start menu, starting with simply searching terminal and pressing enter etc...)

[zadjii-msft]

I think commandline args is more of a stop-gap for now - we're not intending on that being the singular long term solution to this problem. The idea I'm working with (at least in my own head) is to use the commandline args from #4023 to implement this functionality. Possibly as some combination of letting a profile use the arguments to launch multiple tabs/panes at once, and/or letting the user set a startupCommandline to override the defaultProfile on first launch

[zadjii-msft]

Okay I've been noodling on this a bit.

I'm not totally sure that we should have "grouped profiles" - a profile that specifies a bunch of other profiles. That might lead to some unnecessary confusion, especially around the mixing of a "shell" profile and a "group" profile. There's a few scenarios we're looking at here:

• I want to launch the Terminal with a _bunch_ of tabs/panes all at once _by default_, not just from the commandline.
• I want to press a keybinding and have it open a tab with a bunch of panes (or multiple tabs)
• I want to click on an entry in the new tab button and have it open a tab with a bunch of panes (or multiple tabs)

So I think the first one could be satisfied with a defaultLaunchCommandline instead of a defaultProfile, and when that's present, uses that when there's no commandline provided at runtime.

The second will be satisfied by adding "a action that can run a bunch of actions" #5970. Then the user can just run a bunch of things when they press a keybinding.
The third will be satisfied by the "new tab menu customization" #5888 that will let users slam arbitrary actions into that menu. These menu actions could include the "run a bunch of actions" action that is used in the second.

Granted, all this is a showerthought, that needs to be linked to the right threads. Maybe we don't want defaultLaunchCommandline, but defaultActions, that uses a bunch of actions instead of a commandline?

[xmha97]

+1

[7ranceaddic7]

Where is this? What is required to move it forward?

[zadjii-msft]

What is required to move it forward?

Nothing really. Someone needs to probably take my last comment in this thread and turn that into a formal spec (just to make sure the team's on board with the proposed implementation). Once that's approved, it's probably trivial to implement the defaultLaunchCommandline. The #1571 half of this might be harder to implement, but it's already got an approved spec, so that's not a big concern.

Really the main thing that this is blocked on is dev time. There's only so many engineers on the team and there's 1000+ issues on the backlog.

[7ranceaddic7]

Someone needs to probably take my last comment in this thread and turn that into a formal spec

New to this, but I would really appreciate this feature. So, I'll mull it over and advance this.

(google: feature specifications, I did say I was new, but not afraid to jump in the deep-end. )

Thank you for the response.

[joe-mills]

I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well.

[alexbalez]

I'm now just using a shortcut for each project with the wt args I need to open all of the tabs in the right profile, layout, starting directories etc. It works well.

I did this as well to replicate this functionality.

C:Users[name]AppDataLocalMicrosoftWindowsAppswt.exe ; new-tab -p "Ubuntu"; focus-tab -t 0

That will start with two tabs: one with Powershell focused and Ubuntu in the background.