terminal
terminal copied to clipboard
Replace `duplicateTab` with `newTab` with arg
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:
- Deprecate
duplicateTab:- add a
modearg tonewTab. Possible values includeduplicateProfileandduplicatePaneStructure(see #4674). Default value isnull. duplicateTabstill exists, but is just an alias fornewTabwithmode=duplicateProfile.- This gives us
NewTerminalArgsfor free and creates a consistent design across actions creating new panes and new tabs.
- add a
- Split
splitPaneintosplitPaneandduplicatePane:duplicatePanewould have 2 args:sizeandsplit(same behavior as fromsplitPane)- This provides a consistent design, but I feel that it doesn't provide adequate
NewTerminalArgsbenefits.
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
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".
Maybe I was just high on adding args to everything because we could. I never considered if we should 😆
And the pendulum swings. :smile:
Option 2 sounds cool
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.
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?

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