I found discussions mentioning this issue, but they were all closed. However I found this behavior to be unchanged for about a year now

Like we've done with the other issues, could you test the performance of wezterm cli adjust-pane-size --amount 3 Left? You should be able to do this with the time command.

Like we've done with the other issues, could you test the performance of wezterm cli adjust-pane-size --amount 3 Left? You should be able to do this with the time command.

Why adjust-pane-size? I'm not really using it here

Just to narrow down if the issue is the plugin or the wezterm cli, you can try wezterm activate-pane-direction Left instead

Ran this script:

set N 100
set total_time 0

for i in (seq 1 $N)
        set start_time (date +%s%N)
        wezterm cli activate-pane-direction Right
        set end_time (date +%s%N)
        set elapsed (math "($end_time - $start_time)/1000000000")
        set total_time (math "$total_time + $elapsed")
end

set average_time (math "$total_time / $N")

echo "Ran $N times."
echo "Average execution time: $average_time seconds."

And this is the output:
Ran 100 times.
Average execution time: 0.117161 seconds.

Sure, maybe wezterm cli executes not as fast as it could, but I think the problem is that on one single move it here is how much wezterm_exec executes:

wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }
wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }
wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }
wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }
wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }
wezterm_exec: 
{ "wezterm", "cli", "activate-pane-direction", "Right" }
wezterm_exec: 
{ "wezterm", "cli", "list", "--format", "json" }

Investigated this some more and looks like it's a problem with fish:
$ time wezterm cli activate-pane-direction Right

Executed in 122.03 millis fish external
usr time 3.97 millis 439.00 micros 3.53 millis
sys time 13.34 millis 79.00 micros 13.26 millis

In different shells there isn't a delay and time command add some strange time which isn't usr or sys time

Hmm, I'm on Fish shell as well and have never been able to reproduce the performance issues.

Additionally, according to :h system()

If {cmd} is a List it runs directly (no 'shell').

So the shell shouldn't even be involved.

But, if you want to try it, you can try changing the wezterm_exec function to run the command like bash --noprofile --norc -c "wezterm cli whatever-command-here" instead of directly invoking wezterm.

We could also see if changing vim.fn.system(command) to vim.system(command):wait() makes any difference (looks like that's a newer API that's been added since I wrote this code).

Hmm, I'm on Fish shell as well and have never been able to reproduce the performance issues.

Additionally, according to :h system()

If {cmd} is a List it runs directly (no 'shell').

So the shell shouldn't even be involved.

But, if you want to try it, you can try changing the wezterm_exec function to run the command like bash --noprofile --norc -c "wezterm cli whatever-command-here" instead of directly invoking wezterm.

We could also see if changing vim.fn.system(command) to vim.system(command):wait() makes any difference (looks like that's a newer API that's been added since I wrote this code).

Yes, I tested with the new api, but performance was the same
Issue was with my startup speed of fish, which I fixed and there's no delay now.
However it's still really weird, as it shouldn't be involved at all, from what I investigated I couldn't find the route cause
Maybe it's some kind of integration layer thing with wezterm.. but honestly I'm stumped

Now that I'm testing wezterm cli activate-pane-direction also improved after I improved startup time for fish

However it's still really weird, as it shouldn't be involved at all

Yeah, this is the part that I'm still stumped by. I'm passing the command to vim.fn.system(command) as a list, which according to the help docs, means that it shouldn't involve the shell at all.

I wonder if using uv.spawn() would change anything.

Thanks, I thought I was going crazy changing my config, thinking it was my problem. Tks for digging into this.

Btw, i'm using wezterm, zsh and Neovim. No tmux.
My zsh takes a while to load as well (~1 second)

I've removed everything from my .zshrc (compinit, zsh plugins, powerlevel10k, asdf, fzf integration) and smart-splits moved instantly from Neovim to my wezterm pane.

So yeah, it appears that zsh is being called somewhere.

I really do not understand why. According to the Neovim help docs:

{cmd} is treated as in |jobstart()|:
If {cmd} is a List it runs directly (no 'shell').
If {cmd} is a String it runs in the 'shell', like this: >vim
  call jobstart(split(&shell) + split(&shellcmdflag) + ['{cmd}'])

And my code is:

local function wezterm_exec(cmd)
  local command = vim.deepcopy(cmd)
  table.insert(command, 1, config.wezterm_cli_path)
  table.insert(command, 2, 'cli')
  return vim.fn.system(command)
end

It's a list of arguments... why is the shell involved???

I really do not understand why. According to the Neovim help docs:

{cmd} is treated as in |jobstart()|:
If {cmd} is a List it runs directly (no 'shell').
If {cmd} is a String it runs in the 'shell', like this: >vim
  call jobstart(split(&shell) + split(&shellcmdflag) + ['{cmd}'])

And my code is:

local function wezterm_exec(cmd)
  local command = vim.deepcopy(cmd)
  table.insert(command, 1, config.wezterm_cli_path)
  table.insert(command, 2, 'cli')
  return vim.fn.system(command)
end

It's a list of arguments... why is the shell involved???

This is probably a wezterm issue. wezterm cli might use shell in some way (weren't able to reproduce). Or observing an environment variable creates slowdown somehow

Interesting @mister-choo.

It does seem that wezterm does some stuff finding a GUI to connect to and maybe spawning a shell:
https://github.com/wez/wezterm/blob/main/wezterm/src/cli/mod.rs#L168

I'm testing folke's approach to navigate between neovim and wezterm. I've disable smart-splits keymaps and I'm using this:

function M.wezterm()
  local nav = {
    h = "Left",
    j = "Down",
    k = "Up",
    l = "Right",
  }

  local function navigate(dir)
    return function()
      local win = vim.api.nvim_get_current_win()
      vim.cmd.wincmd(dir)
      local pane = vim.env.WEZTERM_PANE
      if vim.system and pane and win == vim.api.nvim_get_current_win() then
        local pane_dir = nav[dir]
        vim.system({ "wezterm", "cli", "activate-pane-direction", pane_dir }, { text = true }, function(p)
          if p.code ~= 0 then
            vim.notify(
              "Failed to move to pane " .. pane_dir .. "\n" .. p.stderr,
              vim.log.levels.ERROR,
              { title = "Wezterm" }
            )
          end
        end)
      end
    end
  end

  -- Move to window using the movement keys
  for key, dir in pairs(nav) do
    vim.keymap.set("n", "<C-" .. key .. ">", navigate(key), { desc = "Go to " .. dir .. " window" })
  end
end

return M

So far, so good, no hanging up, even with my bloated zsh.

Not sure the difference in using vim.system instead of vim.fn.system.

Folke's code: https://github.com/folke/dot/blob/cb1d6f956e0ef1848e57a57c1678d8635980d6c5/nvim/lua/util/init.lua#L109

It could be the difference between vim.fn.system() and vim.system(). I'll put up a PR for yall to test.

Can yall please test #283 and see if that helps

Unfortunately, #283 still didn't do it.

To debug it furter, I've modified wezterm_exec to this:

local function wezterm_exec(cmd)
  if vim.fn.executable(config.wezterm_cli_path) == 0 then
    error(string.format('`%s` is not executable', config.wezterm_cli_path))
  end
  local command = vim.deepcopy(cmd)
  table.insert(command, 1, config.wezterm_cli_path)
  table.insert(command, 2, 'cli')
  vim.print(vim.inspect(command))

  local start_time = vim.loop.hrtime()
  local result = vim.system(command, { text = true }):wait()
  local end_time = vim.loop.hrtime()
  local duration_ms = (end_time - start_time) / 1e6

  vim.print(string.format('Command took %.2fms', duration_ms))

  if result.code == 0 then
    return result.stdout
  else
    return result.stderr
  end
end

Now, the first time I hit C-j, I get this:

{ "wezterm", "cli", "list", "--format", "json" }
Command took 292.81ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 274.99ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 269.63ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 265.17ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 271.35ms
{ "wezterm", "cli", "activate-pane-direction", "Down" }
Command took 16.82ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 14.24ms

If I navigate it again to my Neovim pane and hit C-j a second time, I get much better results:

{ "wezterm", "cli", "list", "--format", "json" }
Command took 16.72ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 19.31ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 14.40ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 14.89ms
{ "wezterm", "cli", "activate-pane-direction", "Down" }
Command took 14.14ms
{ "wezterm", "cli", "list", "--format", "json" }
Command took 14.61ms

So the problem seems to be that wezterm itself takes a long time to run wezterm cli list --format json for the first time, but to be honest whenever I run it in a zsh pane, it runs instantly regardless.

I was also having delay (1-3 seconds) when moving from nvim to wezterm. I found wezterm-move.nvim which I'm using for only the one case of moving from nvim to wezterm. I'm using smart-splits for everything else and it's much better. There's still a small delay, but it's less than 1 second so I can live with that.

I haven't looked into the source code yet, but thought it might be useful for others investigating the issue.

For more context, I use LazyVim and here's some system info:

OS: macOS 15.1.1 24B91 arm64
Shell: zsh 5.9
Terminal: WezTerm