Skip to content
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

split-pane --move-pane-id can kill panes #6028

Open
scauligi opened this issue Aug 25, 2024 · 2 comments · May be fixed by #6029
Open

split-pane --move-pane-id can kill panes #6028

scauligi opened this issue Aug 25, 2024 · 2 comments · May be fixed by #6029
Labels
bug Something isn't working

Comments

@scauligi
Copy link

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

AeroSpace

WezTerm version

20240203-110809-5046fc22 + main

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Example:

+-----+
|  A  |
+-----+
|  B  |
+-----+

Command: split-pane --pane-id $B_PANE_ID --move-pane-id $A_PANE_ID

In Domain::split_pane (in mux/src/domain.rs), with a SplitSource::MovePane, the splitting pane (pane B) is first translated into a pane index (1) for its tab. Then, pane A is removed from its tab. However, this changes pane B's index (now 0). Subsequently, when we call tab.split_and_insert(b_old_index, ..., the old index 1 is incorrect; in this example it is in fact invalid as there is only a single pane, and pane A never gets reattached to the tab.

To Reproduce

In a new tab, split the pane vertically. In the bottom pane, run:
wezterm cli split-pane --move-pane-id $(wezterm cli get-pane-direction up)

Configuration

no config

Expected Behavior

Top pane should be moved into the right side of a horizontal split of the previously bottom pane.

Logs

No response

Anything else?

No response

@scauligi scauligi added the bug Something isn't working label Aug 25, 2024
@scauligi scauligi linked a pull request Aug 25, 2024 that will close this issue
@goerz
Copy link

goerz commented Sep 30, 2024

I might be misunderstanding your report, but are you aware that the pane ID is not the same as the tab ID and the tab ID is not the same as the tab index (the number shown in the GUI if show_tab_index_in_tab_bar = true)?. Tab indices change when panes/tabs get moved, but the IDs (which you can see with wezterm cli list) should stay the same

@scauligi
Copy link
Author

scauligi commented Oct 6, 2024

Yup! The problem is that the code itself translates the pane ID into a pane index (of the array of panes); when the pane is removed from the tab, that index may change. You can see the linked PR for how the issue arises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants