Support tmux's target-pane and target-window syntax for finding an existing runner

[mvanderkamp]

This is intended to resolve #206

I figured a new option would be appropriate, instead of shoe-horning this into the VimuxUseNearest/VimuxRunnerName combo. I've given this one precedent since it (mostly) covers the use cases provided by that combo.

I say mostly because it doesn't look like tmux supports querying for a pane's title in the same way you can query for a window or session name, at least not the version I'm currently using (3.2a). So that's one possible case where VimuxRunnerName provides functionality that the new VimuxRunnerQuery doesn't. My read on it though is that the "runner name" was mostly for windows, but perhaps I'm mistaken? In any case, it's still fine to use that option if someone wants to.

[kevinhughes27]

This commit broke VimuxUseNearest = 0. Instead of opening a new pane it inserts the output into the current buffer. Pinning the plugin to the commit before this was merged fixes it for me.

 ❯ tmux -V
tmux 3.3a

[mvanderkamp]

I can't reproduce- have you changed any other vimux settings?

[kevinhughes27]

This is my config:

  use {
    'benmills/vimux',
    commit = "89604a4464c3069dbe31f7bc8dd16a5fbc88a303", -- https://github.com/preservim/vimux/pull/210
  }
  use {
    'vim-test/vim-test',
    config = function()
      vim.g['test#strategy'] = 'vimux' -- make test commands execute using vimux
      vim.g['test#python#runner'] = 'pytest' -- have to configure which python runner to use https://github.com/vim-test/vim-test#python
      vim.g['VimuxUseNearest'] = 0 -- don't use an exisiting pane
      vim.g['VimuxHeight'] = '25'
    end
  }

For me it was reproducible with VimuxRunCommand("echo wat") although I first noticed it through vim-test.

This is inside a linux vm running tmux on my work M1. I can confirm if this happens on my simpler personal setup as well and report back.

[kevinhughes27]

In a strange turn of events I can reproduce on my plain linux desktop but pinning back the plugin doesn't seem to fix it there 🤔

desktop is tmux 3.4 that I built so I will try newer and the latest stable there as well.

[kevinhughes27]

tmux 3.3a with the plugin pinned works again. Something in tmux-next-3.4 breaks it again

[mvanderkamp]

Are you using the same version of vim in both cases?

[kevinhughes27]

I am using a neovim nightly on both machines. Unlikely it is the exact same version

[mvanderkamp]

Hmm I wonder if this is a vim/neovim compatibility issue. It sounds like a few things are going wrong:

• It's either interpreting VimuxUseNearest = 0 as true or incorrectly interpreting the default path for VimuxRunnerQuery
• It then fails to skip the current pane when finding the runner.

I don't use neovim so I can't guess offhand why any of that would be happening.

[mvanderkamp]

Can you try the branch issue-210-hotfix to see if that helps? It's a stab in the dark by adding some guardrails around the logic.

[kevinhughes27]

@mvanderkamp that fixes it on both of my machines!

[mvanderkamp]

K I've opened it as #215, though I've marked it as a draft for now so I can do a bit more manual testing.