mrjones2014 / smart-splits.nvim

🧠 Smart, seamless, directional navigation and resizing of Neovim + terminal multiplexer splits. Supports tmux, Wezterm, and Kitty. Think about splits in terms of "up/down/left/right".
MIT License
895 stars 37 forks source link

[Bug]: Switching between neovim and wezterm panes when using wezterm ssh client does not work #163

Open oddnugget opened 6 months ago

oddnugget commented 6 months ago

Similar Issues

Neovim Version

NVIM v0.9.5
Build type: RelWithDebInfo
LuaJIT 2.1.1692716794

Multiplexer Integration

Wezterm

Multiplexer Version

wezterm 20240203-110809-5046fc22

Steps to Reproduce

  1. Setup keybinds as per README in wezterm and neovim
  2. Run wezterm ssh <your-host>
  3. Open nvim
  4. Create a new pane
  5. Attempt to navigate back to nvim pane
    • It works!
  6. Attempt to navigate out of neovim to the initial pane.
    • It doesn't work

Expected Behavior

You should be able to navigate out of neovim split in a wezterm ssh <host> session.

Actual Behavior

You can only navigate to an neovim split, not out of it.

Minimal Configuration to Reproduce

local root = vim.fn.fnamemodify('./.repro', ':p')

-- set stdpaths to use .repro
for _, name in ipairs({ 'config', 'data', 'state', 'cache' }) do
  vim.env[('XDG_%s_HOME'):format(name:upper())] = root .. '/' .. name
end

-- bootstrap lazy
local lazypath = root .. '/plugins/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    'git',
    'clone',
    '--filter=blob:none',
    '--single-branch',
    'https://github.com/folke/lazy.nvim.git',
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  -- do not remove the colorscheme! it makes testing nicer
  'folke/tokyonight.nvim',
  'mrjones2014/smart-splits.nvim',
  -- add any other pugins here
}

require('lazy').setup(plugins, {
  root = root .. '/plugins',
})

require('smart-splits').setup({
  -- add any options here
})

)
-- moving between splits
vim.keymap.set('n', '<C-h>', require('smart-splits').move_cursor_left)
vim.keymap.set('n', '<C-j>', require('smart-splits').move_cursor_down)
vim.keymap.set('n', '<C-k>', require('smart-splits').move_cursor_up)
vim.keymap.set('n', '<C-l>', require('smart-splits').move_cursor_right)

-- add anything else here
vim.opt.termguicolors = true
-- do not remove the colorscheme! it makes testing nicer
vim.cmd([[colorscheme tokyonight]])

Additional Details and/or Screenshots

I've been digging around a bit on this one, and from what i can gather it is only an issue when using wezterms built in ssh client, e.g if if i run ssh <host> switching between panes works.

I've set up the shell-integrations as per the instructions in the wezterm docs: https://github.com/wez/wezterm/blob/main/assets/shell-integration/wezterm.sh and can confirm that the IS_NVIM user var is being set correctly and is accessible from outside the remote host.

I can't see anything interesting in :SmartSplitsLog

It seems that the call to wezterm_exec({ 'get-pane-direction', direction }) here https://github.com/mrjones2014/smart-splits.nvim/blob/78f0c74ea1d5aa1725ab63b25761886245622904/lua/smart-splits/mux/wezterm.lua#L97C1-L97C43 doesn't return anything.

Running the command in bash on the remote host gives the following error:

ERROR  wezterm > --pane-id was not specified and $WEZTERM_PANE~~
                        is not set in the environment, and I couldn't
                         determine which pane was currently focused; terminating

Edit: though that might be because i didn't specify it when running the command

oddnugget commented 6 months ago

related: https://github.com/mrjones2014/smart-splits.nvim/pull/105 https://github.com/mrjones2014/smart-splits.nvim/issues/103

mrjones2014 commented 6 months ago

Hm, the issue is because of $WEZTERM_PANE not being set in the SSH session, but I'm not sure how to work around it.

oddnugget commented 6 months ago

Hmm ok. Sounds like more of a wezterm issue then

oddnugget commented 6 months ago

It seems to work when connecting to the persistent ssh domain instead of the ad-hoc one. e.g wezterm connect <domain>

mrjones2014 commented 6 months ago

In the case where it doesn't work, if you run wezterm cli list --format json does it show the correct pane as active? If so we can work around it by using that to get the active pane ID instead of relying on $WEZTERM_PANE and then passing --pane-id

oddnugget commented 6 months ago

In the case where it doesn't work, if you run wezterm cli list --format json does it show the correct pane as active? If so we can work around it by using that to get the active pane ID instead of relying on $WEZTERM_PANE and then passing --pane-id

It just returns an empty list :/

But I'm unsure how that connection would work anyway, how should the wezterm cli running on the remote machine know things about the local wezterm gui.

My guess is when connecting using the persistent ssh domain it uses the socket somehow.

carmen-gh commented 4 months ago

Interesting. I have the same issue but even without an ssh connection. Just wezterm and Neovim

mochouaaaaa commented 3 months ago

Interesting. I have the same issue but even without an ssh connection. Just wezterm and Neovim

I'm in the same situation as you, and so far I've come to the conclusion that neovim doesn't receive key events, but inside neovim you can see that shortcuts have been bound via :verbose map .

But when I use vim.notify to throw an exception in the smart-splits source code, the shortcut is again available using the.

function M.get()
  if
    config.multiplexer_integration == nil
    or config.multiplexer_integration == false
    or #tostring(config.multiplexer_integration or '') == 0
  then
    return nil
  end

  local ok, mux = pcall(require, string.format('smart-splits.mux.%s', config.multiplexer_integration))
  print(ok)  # no error
  print(vim.inspect(mux))  # no error
  vim.notify(ok)  # error
  if not ok then
    log.error(mux)
  end
  return ok and mux or nil
end
mrjones2014 commented 3 months ago

Interesting. Could you open a separate issue for that?

mochouaaaaa commented 3 months ago

Interesting. Could you open a separate issue for that?

212

mrjones2014 commented 3 months ago

is because of $WEZTERM_PANE not being set in the SSH session

Pretty sure it's all related to this. Still investigating.

mrjones2014 commented 3 months ago

See also: https://github.com/wez/wezterm/discussions/5378#discussioncomment-9377194

It should be something like AcceptEnv WEZTERM_PANE on the server, and maybe some client config. However I've been unable to get a working SSH config.

mrjones2014 commented 1 month ago

So I can reproduce this with normal ssh but I actually cannot reproduce using wezterm ssh