Tab navigation gets confused after move-pane-to-new-tab

[junkblocker]

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

Linux X11

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

No response

WezTerm version

wezterm 20230325-203323-59503034

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

ActivateTab gets confused after move-pane-to-new-tab and jumping to the split tab and other tabs doesn't go to the right tab number. I suspect that the new split tab still thinks it has the old tab number.

To Reproduce

1. Open a fresh wezterm session.
2. Create a split pane Ctrl+a |.
3. Create a new tab Ctrl+a c.
4. Go to original tab 0 Ctrl+a 0.
5. Detach pane Ctrl+a !. [Note that the split went to tab 2]
6. Create a new tab Ctrl+a c.
7. Navigate to tabs in sequence. Ctrl+a 0
8. Navigate to tabs in sequence. Ctrl+a 1
9. Navigate to tabs in sequence. Ctrl+a 2
10. Navigate to tabs in sequence. Ctrl+a 3
11. Navigate to tabs in sequence. Ctrl+a 0
12. Navigate to tabs in sequence. Ctrl+a 1
13. Navigate to tabs in sequence. Ctrl+a 2
14. Navigate to tabs in sequence. Ctrl+a 3

Navigating to tab 2 always goes to tab 0 instead.

Configuration

local wezterm = require "wezterm"
local callback = wezterm.action_callback
if true then
    return {
        tab_and_split_indices_are_zero_based = true,
        automatically_reload_config = true,
        leader = { key = "a", mods = "CTRL", timeout_milliseconds = 5000 },
        keys = {
            { key = "!", mods = "LEADER | SHIFT", action = callback(
                function(win, pane)
                    wezterm.run_child_process({
                        'wezterm',
                        'cli',
                        'move-pane-to-new-tab',
                        '--pane-id',
                        tostring(pane:pane_id())})
                end)
            },
            { key = "|", mods = "LEADER", action = { SplitHorizontal = { domain = "CurrentPaneDomain" }}},
            { key = "|", mods = "LEADER|SHIFT", action = { SplitHorizontal = { domain = "CurrentPaneDomain" }}},
            { key = "-", mods = "LEADER", action = { SplitVertical = { domain = "CurrentPaneDomain" }}},
            { key = "c", mods = "LEADER", action = { SpawnTab = "CurrentPaneDomain" }},
            { key = "0", mods = "LEADER", action = { ActivateTab = 0 }},
            { key = "1", mods = "LEADER", action = { ActivateTab = 1 }},
            { key = "2", mods = "LEADER", action = { ActivateTab = 2 }},
            { key = "3", mods = "LEADER", action = { ActivateTab = 3 }},
            { key = "4", mods = "LEADER", action = { ActivateTab = 4 }},
            { key = "5", mods = "LEADER", action = { ActivateTab = 5 }},
            { key = "6", mods = "LEADER", action = { ActivateTab = 6 }},
            { key = "7", mods = "LEADER", action = { ActivateTab = 7 }},
            { key = "8", mods = "LEADER", action = { ActivateTab = 8 }},
            { key = "9", mods = "LEADER", action = { ActivateTab = 9 }},
        },
        debug_key_events = true,
        default_domain = 'unix',
        unix_domains = {
            {
                name = 'unix',
            },
        }
    }
end

Expected Behavior

The navigation to tab 2 should go to tab 2 instead of tab 0.

Logs

Not provided. A different key than Ctrl+a ! e.g. Ctrl+a t can be used if there are any mapping issues.

Anything else?

No response

[wez]

Interesting! The workaround is to do this:

                    wezterm.run_child_process({
                        'env',
                        'WEZTERM_UNIX_SOCKET=/Users/wez/.local/share/wezterm/sock',
                        'wezterm',
                        'cli',
                        'move-pane-to-new-tab',
                        '--pane-id',
                        tostring(pane:pane_id())})

The issue is that the move tab request is being made to the mux in the gui, rather than the mux server, so the pane doesn't really get move in the way that you expect. You can see it in a wonky state if you wezterm cli list immediately after moving the pane to a new tab.

By setting the WEZTERM_UNIX_SOCKET env explicitly to match that of the mux server, the issue is avoided.

This needs a more robust solution, but that should get you unblocked for now.

[wez]

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[wez]

latest main will let you do this:

            { key = "!", mods = "LEADER | SHIFT", action = callback(
                function(win, pane)
                    pane:move_to_new_tab()
                end)
            },

[junkblocker]

Thanks. That including the lua API works correctly now!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.