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

[scauligi]

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

[goerz]

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]

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.