New Tab Button should open the active profile instead of default

[Wynadorn]

Description of the new feature/enhancement

Currently the new tab button opens a terminal the default profile. So for example, with my default set to WSL: Debian, the new tab button will always open with that profile.

Instead I think it'd be nice to have the new tab button open a terminal using the same profile as the currently active tab. This way if I have a non-default profile open, such as PowerShell, the + button would open a new PowerShell tab instead.

Proposed technical implementation details

The default profile could have an additional setting called Currently Active. When a new tab is opened you'd need a way to retrieve the profile of the currently active tab, then open the new tab using that profile.

[zadjii-msft]

You know, I could have sworn we had a discussion thread already for "change the new tab button to duplicate the current pane rather than use the default profile" but I can't seem to find that discussion

[Wynadorn]

You know, I could have sworn we had a discussion thread already for "change the new tab button to duplicate the current pane rather than use the default profile" but I can't seem to find that discussion

I've tried looking for it beforehand but didn't come across anything either.

However I think I did see some that mention similar functionality when splitting an existing pane.

[zadjii-msft]

You know, I might be wrong about that. I had this in my list of "issues to post in the future"

Add a setting to default the new tab button to "duplicate tab" instead of "open default profile"

Maybe that applies to the splitPane actions as well?

Is this just asking for "toolbar customization" though? Should this be an extension? How would we let an extension do that?

Would they get at the tab row, hide the new tab button, then add their own split button, with the same new tab menu, but with duplicateTab bound instead?

Crazy shower thought:

"newTabButton": {
  "action": { /* duplicate tab*/ },
  "icon": "whatever",
  "showDropdown": false
}

Also related: #6685

[Wynadorn]

Maybe that applies to the splitPane actions as well?
Is this just asking for "toolbar customization" though? Should this be an extension? How would we let an extension do that?

Although I think it's out of scope for this Feature-Request. The above is a request for taskbar customization, while #11337 is about expanding the defaultProfile setting which is part of the new tab command.

Either way I suppose there could be some demand for a splitPane button or taskbar customization.

On the GUI side of things, currently the buttons next to the tab bar consist of a left and a right button:

I suppose a good way to implement toolbar customization would be to have additional buttons shown in the middle. Maybe a config could allow for n buttons to be defined, where in "+" being the first button and any additional buttons are placed in between.

[Wynadorn]

Semi-related, if you really want buttons which open a new tab to a specific profile, here's a clean workaround:

Create some shortcuts with targets similar to the following:
wt.exe -w 0 -p "PowerShell Core"
wt.exe -w 0 -p "Command Prompt"
wt.exe -w 0 -p "Debian"
-w 0 opens a profile as a tab as window 0

Result:

[stephenmartindale]

I'd like to weigh in, here, and add that this feature (or feature group) would be pretty vital, for me. For example, one of my most common invocations of wt goes something like this:

"%localappdata%\Microsoft\WindowsApps\wt.exe" --window SSH new-tab --profile "SSH :: servername"

To me, it makes absolutely no sense that subsequently, in the window that appears, both the split-pane commands and the default new-tab button open cmd.exe (my default profile) on the local machine. This feature is just as important for split-pane as it is for new-tab -- if not more so.

Similarly, if I start wt with the --commandline set, I might do something like this:

%localappdata%\Microsoft\WindowsApps\wt.exe new-tab --commandline %SystemRoot%\System32\cmd.exe /c "path/to/python-environment.bat && python.exe path/to/interactive/program.py"

... and I would expect that new-tabs and split-panes would also apply my --commandline command-line. (And, logically, the starting directory etc.)

At the very least, all of the above should be optional behaviour modes. Even if they do not match everybody's use-case, the above two cover pretty much 99% of my workflows with wt and I'm certain that I am not alone in this. My other use-cases (git bash, W.S.L. sessions, very occasional PowerShell usage) would also all benefit from such a behaviour mode because, when I'm in PowerShell, for example, I really really do not expect a split-pane to be cmd.exe.

[zadjii-msft]

@stephenmartindale you may be interested in duplicateTab and "duplicate pane", { "command": { "action": "splitPane", "split": "auto", "splitMode": "duplicate" }, "keys": "alt+shift+d" }

these might be reasonable workarounds while we work on this 😄

[stephenmartindale]

... you may be interested in duplicateTab and "duplicate pane", { "command": { "action": "splitPane", "split": "auto", "splitMode": "duplicate" }, "keys": "alt+shift+d" }

these might be reasonable workarounds while we work on this 😄

They are not. The existing "duplicate" behaviour does not create a duplicate. It respects the profile, but not command-line and starting directory.

[zadjii-msft]

Ah, right, I forgot we haven't gotten around to #5047 (comment) yet. That'll help with your scenario

[stephenmartindale]

Issue logged: #11678

[Rosefield]

I believe, but have not tested, that if Pane::GetTerminalArgsForPane is used for duplicating that it contains the logic to resolve this issue. https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L122

[PathogenDavid]

I tinkered on this a bit out of curiosity and it turned out to be pretty easy to implement: https://github.com/PathogenDavid/windows-terminal/commit/67a370e5ab5168598fa48491f22c40b5d7ca36fe

diff --git a/src/cascadia/TerminalApp/TerminalPage.cpp b/src/cascadia/TerminalApp/TerminalPage.cpp
index 752e8e590..96b80f16a 100644
--- a/src/cascadia/TerminalApp/TerminalPage.cpp
+++ b/src/cascadia/TerminalApp/TerminalPage.cpp
@@ -214,5 +214,13 @@ namespace winrt::TerminalApp::implementation
             if (auto page{ weakThis.get() })
             {
-                page->_OpenNewTerminal(NewTerminalArgs());
+                // Duplicate the focused terminal if there is one, otherwise create one from the default profile
+                if (const auto focusedTab{ page->_GetFocusedTabImpl() })
+                {
+                    page->_DuplicateTab(*focusedTab);
+                }
+                else
+                {
+                    page->_OpenNewTerminal(NewTerminalArgs());
+                }
             }
         });

(Unfortunately I'm not very confident I'll have any time soon to formalize it enough to make it a proper contribution, but maybe I'll save someone else a bit of time investigating.)

Edit: Worth noting that this doesn't handle the keyboard shortcuts, just clicking the button. Ctrl+Shift+T comes in in TerminalPage::_HandleNewTab and it already has NewTerminalArgs originating somewhere in the keyboard shortcut event handling schmoo, might look into that more later too.

[zadjii-msft]

Lawdy, look at that. Digging through the backlog, this looks like it is a /dup of #445. I'm gonna leave that one open since it has more 👍's. I've moved a bunch of relevant comments to that thread.

Thanks all!

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!