-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate active half when duplicating split pane #13579
Comments
Yes, but I'm actually referring to the "Duplicate Tab" option. Open a tab, split it, change the directory on one half, then duplicate it, and the new tab created by the duplication has the path of one or the other of the split tab's panes, obviously. The problem is that it's very insistent on using whichever pane it feels like for the path in the new, duplicated tab. When I first tested it, it was always the right pane. Testing again just now, it was the left pane, then somehow I got it to switch to using the path from the right pane and I can't get it to switch back. It should use the path from whichever pane is active when the tab is duplicated. The same problem applies to splitting an already split tab. The new pane has the same behavior as the new tab created when duplicating, and should have the path of the active pane when the tab is further split. |
To add to this, I've found more unexpected behavior I think may be related. I have the starting directory for a new tab set to use the parent process directory, which I apparently wrongfully assumed meant the parent tab, but AFAICT it uses the first tab's CWD. This appears to be what issue #3158 deals with, and if that's correct this isn't a bug, but definitely, as mentioned, unexpected. However, what definitely does appear to be a bug is that even duplicating a tab results in the new tab having the CWD of the first tab, and I suspect that's the source of the previously mentioned problems. |
Hello. I was about to create my own issue with a somewhate-related subject: shouldn't the "Duplicate tab" duplicate also the split pane layout? |
To add, I think this was fixed at some point in the past. I at least can't repro it on the 1.18 selfhost build build I'm on currently. I'd suspect this was at least fixed in 1.17, probably sooner. I can't really recall which PR fixed this. Of course, duplicating the CWD of a pane that assumes that you've got shell integration enabled, but this all looks working to me. I tried both
and also
|
@zadjii-msft Thanks for your reply. [EDITED]
My expectation is: having a new second tab split in two panes too! I don't need the CWD to be kept, I'm just talking about tab layout. For my understanding, shell integration enabled is only to enable CWD (current working directory), and not about split tabs. Correct me if I'm wrong! Sorry again if I'm not clear enough. |
@zadjii-msft After more reading, I can confirm that what I'm asking for is #4674: when using the "Duplicate tab" feature, panes should be kept the same (so if a tab is split in 3 panes, "Duplicate tab" should create a new tab with 3 panes in it). |
This PR's goal is to allow something like a `Tab` to raise a ShortcutAction, by saying "this action should be performed on ME". We've had a whole category of these issues in the past: * #15734 * #15760 * #13579 * #13942 * #13942 * Heck even dating back to #10832 So, this tries to remove a bit of that footgun. This probably isn't the _final_ form of what this refactor might look like, but the code is certainly better than before. Basically, there's a few bits: * `ShortcutActionDispatch.DoAction` now takes a `sender`, which can be _anything_. * Most actions that use a "Get the focused _thing_ then do something to it" are changed to "If there was a sender, let's use that - otherwise, we'll use the focused _thing_". * TerminalTab was largely refactored to use this, instead of making requests to the `TerminalPage` to just do a thing to it. I've got a few TODO!s left, but wanted to get initial feedback. * [x] `TerminalPage::_HandleTogglePaneZoom` * [x] `TerminalPage::_HandleFocusPane` * [x] `TerminalPage::_MoveTab` Closes #15734
This PR's goal is to allow something like a `Tab` to raise a ShortcutAction, by saying "this action should be performed on ME". We've had a whole category of these issues in the past: * #15734 * #15760 * #13579 * #13942 * #13942 * Heck even dating back to #10832 So, this tries to remove a bit of that footgun. This probably isn't the _final_ form of what this refactor might look like, but the code is certainly better than before. Basically, there's a few bits: * `ShortcutActionDispatch.DoAction` now takes a `sender`, which can be _anything_. * Most actions that use a "Get the focused _thing_ then do something to it" are changed to "If there was a sender, let's use that - otherwise, we'll use the focused _thing_". * TerminalTab was largely refactored to use this, instead of making requests to the `TerminalPage` to just do a thing to it. I've got a few TODO!s left, but wanted to get initial feedback. * [x] `TerminalPage::_HandleTogglePaneZoom` * [x] `TerminalPage::_HandleFocusPane` * [x] `TerminalPage::_MoveTab` Closes #15734 (cherry picked from commit 30eb9ee) Service-Card-Id: 90438493 Service-Version: 1.18
Description of the new feature/enhancement
When a pane is split then duplicated, the right half is always the one duplicated. It should duplicate whichever half has focus when right-clicking the tab.
Proposed technical implementation details (optional)
The text was updated successfully, but these errors were encountered: