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 #3037 (comment)

[ItsMeBrianD]

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.

[GordonSmith]

@zadjii-msft multiple panes would be a different issue request surely.

Clicking the newTab button could open a new terminal matching the one to its left (but yes I do take your point :)).

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

...rant over...

[zadjii-msft]

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

Ah but see, part of my job is to make sure we design holistic solutions to problems. When there's such a obvious follow up feature, then it makes sense to think of not how to just solve the issue at hand, but also the follow up, in a single design. I don't want to have to build a solution for opening with multiple tabs, then build a solution for opening with multiple panes, then a solution for tabs, panes, and other actions, if it's clear from the onset where we want this feature to go.

We've only got so many engineers on the team, so there's only so much we can work on at a time. This is still in-scope for 2.0, so don't worry, be patient! This will come Soon^TM

[joe-mills]

But this is an issue opened May 2019 with what appears to be a straightforward request "Start with multiple tabs open" and its frustrating when it gets derailed with additional capabilities (panes).

Tabs contain panes so surely its a necessary part of the original "Start with multiple tabs open". I think it gets confusing because currently profiles don't support multiple shells. The little plus button or launcher opens a profile as a tab or a pane which only makes sense when a profile is a single shell.

All of the wt arguments to configure how a tab and panes open are already available for what most want, it seems like its more of a UI challenge.

[GordonSmith]

@joe-mills if you can specify several panes for a single profile, then that will just work? If not then I would suggest making that a different issue.

Formal Spec II:

• Add a new setting homeProfiles, an optional string array of profile guids which will open as individual tabs on terminal launch.
• When omitted the current behaviour should be observed (open a single instance of defaultProfile).

[joe-mills]

@GordonSmith I guess this might sound like a stupid question but what is a profile supposed to represent?

[zadjii-msft]

Discussion that I had with @DHowett that I don't want to forget:

• It's pretty much trivial to implement "startupActions": "new-tab ; split-pane -p PowerShell" today. This would be a "proceedural" style solution
• We might want in the future to also do a "declarative" style solution, which would be more like "startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }. (typing that out did feel gross though)
• We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code yet

[Don-Vito]

Discussion that I had with @DHowett that I don't want to forget:

* It's pretty much trivial to implement `"startupActions": "new-tab ; split-pane -p PowerShell"` today. This would be a "proceedural" style solution

* We might want in the future to also do a "declarative" style solution, which would be more like `"startupLayout": { "tabs": [ {"panes": { "profile": "PowerShell", "size": 0.50 }, { "profile": "Ubuntu", "size": 0.50 } } ] }`. (typing that out did feel gross though)

* We're going to need some sort of declarative layout for session restore and tearout anyways, but we don't have any of that code _yet_

@zadjii-msft - what should be the behavior of startupActions (and of additional approaches) when we get command line arguments as well:

• Should we use command line arguments only?
• Should we concat the command line arguments with startupActions. If so
  • In what order?
  • If the second part doesn't start with the new-tab - should we still insert it or to continue applying the actions on the current tab?

[zadjii-msft]

I'd expect that not by providing commandline args, that would override the startupActions. So wt new-tab would still just open a single tab with the default profile, even if there's a longer startupActions set. That way you could still manually get a specific layout, even with startupActions set. I'm thinking maybe some tool out there wants to ship a helper script to open a WT window with some pre-configured tabs. By overriding the startupActions with the commandline that's passed in, we allow this scenario to still work as expected.

We had discussed limiting startupActions to the actions that are also commandline subcommands, because those are the ones that we know will work during startup.

I believe we also at one point discussed that startupActions should also use the implicit new-tab - if the first command isn't new-tab, we should insert one at the start.

[Don-Vito]

oint discussed that startupActions should also use the implicit new-tab - if the first command isn't new-tab, we should insert one at the start.

Makes sense! If I you are OK with it, I will try to add something like this.. Sounds straightforward (famous last words).

[Makishima]

Just want to show up my case:
I'm interested in to start wt with few tabs - wsl and PS but when hit 'New tab' I'm often want to open just new wsl only

[zadjii-msft]

You know, startupActions is a perfectly good answer to this problem. I don't think this needs to be left open any longer.

[maicol07]

There are actually two issues:

• Tabs have all the same title
• Only the first tab is opened when opening the Terminal from he right click menu in explorer