Replace duplicateTab with newTab with arg

[carlos-zamora]

Description of the new feature/enhancement

duplicateTab and newTab are two different actions whereas splitPane accomplishes the functionality of both "duplicate my current pane" and "open a new pane". splitPane also lets the user use NewTerminalArgs to customize a duplicate pane.

I propose we do one of the following:

1. Deprecate duplicateTab:
   • add a mode arg to newTab. Possible values include duplicateProfile and duplicatePaneStructure (see Duplicate Tab doesn't duplicate split panes #4674). Default value is null.
   • duplicateTab still exists, but is just an alias for newTab with mode=duplicateProfile.
   • This gives us NewTerminalArgs for free and creates a consistent design across actions creating new panes and new tabs.
2. Split splitPane into splitPane and duplicatePane:
   • duplicatePane would have 2 args: size and split (same behavior as from splitPane)
   • This provides a consistent design, but I feel that it doesn't provide adequate NewTerminalArgs benefits.

Other comments

Inspired by a comment made by @lhecker
#4674 Should be kept in mind with the new design.
I'm open to other ideas or different names for these actions/args.

Resources

duplicateTab docs
newTab docs
splitPane docs

[zadjii-msft]

gods I hate this. I already deeply regret making "duplicate pane" an argument to splitPane instead of a separate action. I'm not sure there's anyone using "duplicate pane, but also I want x, y, and z to actually have the values foo, bar, baz". It means that there's this long, verbose action just for duplicate pane, and that's annoying. duplicatePane would have just been easier. Maybe I was just high on adding args to everything because we could. I never considered if we should 😆

I'd definitely prefer the second option, the "make a duplicatePane action" route. We can still throw args in duplicateTab for "duplicatePaneStructure: bool".

[DHowett]

Maybe I was just high on adding args to everything because we could. I never considered if we should 😆

And the pendulum swings. 😄

[zadjii-msft]

Option 2 sounds cool

[carlos-zamora]

We've decided on option 1. Mainly because of #10232, #12985, and #14350.

We need to add duplicate: {true|false} to NewTerminalArgs, and make sure that new tab, new window code knows how to handle this.

We can promote that to an enum when we get to #4674.

[Aymkdn]

Will this change permit to set the default behavior of the "new" button as a duplicate/clone of the current tab?

So when clicking on "new", we could duplicate the current tab instead of using the "Duplicate" menu?

[zadjii-msft]

@Aymkdn This by itself - no. That we're tracking in #445.