[WINDOWS] Wezterm multiplexer navigation in neovim not working

[jeeeem]

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

Windows

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

No response

WezTerm version

wezterm 20230421-075330-e0a92c73

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

I already tried https://github.com/mrjones2014/smart-splits.nvim and https://github.com/numToStr/Navigator.nvim to integrate the navigation in wezterm in windows but its not working. Im not sure what is happening but when I configure the navigation key to <C-{h-j-l-k}> keys from neovim and wezterm for the integration to work, the pane navigation in wezterm is working with ctrl+ navigation keys but inside the neovim something weird is happening, It is working but with different keys, it is using ctrl+alt+ navigation keys to navigate not the <ctrl+ keymaps, and im not sure why it is happening.

To Reproduce

Use this minimal init config

https://github.com/mrjones2014/smart-splits.nvim/discussions/72

and add this config in the wezterm config

https://github.com/mrjones2014/smart-splits.nvim#wezterm

Configuration

no config

Expected Behavior

Should be able to navigate smoothly like tmux integration with vim using ctrl+ keymap

Logs

No response

Anything else?

No response

[jeeeem]

Is this windows-centric issue?

[Goxore]

pane:get_foreground_process_name() does not include any mention of vim/nvim when it is a foreground process for me on my windows work machine, that might be the issue

[wez]

cc: @mrjones2014 in case they have any insights.

I'd recommend following the https://wezfurlong.org/wezterm/troubleshooting.html#debugging-keyboard-related-issues troubleshooting steps to log what keys are being pressed.

You may also want to try setting allow_win32_input_mode = false.

[mrjones2014]

pane:get_foreground_process_name() does not include any mention of vim/nvim when it is a foreground process for me on my windows work machine, that might be the issue

this is definitely the root issue then because otherwise the wezterm maps don't know to pass the keymap through to the process instead of handling them in wezterm itself. Here's effectively how the keys are mapped in the wezterm config:

local w = require('wezterm')

-- Equivalent to POSIX basename(3)
-- Given "/foo/bar" returns "bar"
-- Given "c:\\foo\\bar" returns "bar"
local function basename(s)
  return string.gsub(s, '(.*[/\\])(.*)', '%2')
end

local function is_vim(pane)
  local process_name = basename(pane:get_foreground_process_name())
  return process_name == 'nvim' or process_name == 'vim'
end

local direction_keys = {
  Left = 'h',
  Down = 'j',
  Up = 'k',
  Right = 'l',
  -- reverse lookup
  h = 'Left',
  j = 'Down',
  k = 'Up',
  l = 'Right',
}

local function split_nav(resize_or_move, key)
  return {
    key = key,
    mods = resize_or_move == 'resize' and 'META' or 'CTRL',
    action = w.action_callback(function(win, pane)
      if is_vim(pane) then
        -- pass the keys through to vim/nvim
        win:perform_action({
          SendKey = { key = key, mods = resize_or_move == 'resize' and 'META' or 'CTRL' },
        }, pane)
      else
        if resize_or_move == 'resize' then
          win:perform_action({ AdjustPaneSize = { direction_keys[key], 3 } }, pane)
        else
          win:perform_action({ ActivatePaneDirection = direction_keys[key] }, pane)
        end
      end
    end),
  }
end

[mrjones2014]

I'm not sure what the cause is, I know this happens on Linux if you use flatpak because of the sandboxing.

If its an issue like that, we could also solve this with wezterm user vars, but that would require setting nvim to a shell alias in your shell config.

[abusch]

FWIW I had this issue on MacOS with nushell but this was due to nushell not setting the foreground process name properly on this platform. I had to work around it by matching on pane:get_title() instead and setting set title in vim.

[mrjones2014]

Confirmed in https://github.com/mrjones2014/smart-splits.nvim/issues/94#issuecomment-1520428586 that this is user error

[jeeeem]

Sorry for the late reply, but this is not fix yet in WINDOWS env, https://github.com/mrjones2014/smart-splits.nvim/issues/94#issuecomment-1527117205 , the above user error is using arch linux, not windows.

pane:get_foreground_process_name() does not include any mention of vim/nvim when it is a foreground process for me on my windows work machine, that might be the issue

Just like he said, also the same for me. Alhough I did a work around just like @abusch, still not working.

[SilverMira]

It seems like pane:get_foreground_process_name() may somehow instead retrieve one of the child process of the actual foreground process on Windows, lua-language-server.exe was running due to LSP.

[mrjones2014]

I'd like to know if there is an actual bug here in Wezterm, but we could also work around this if you're willing to alias the nvim command in your shell by using user vars: https://wezfurlong.org/wezterm/shell-integration.html

We just need to know whether nvim is running in a pane, which we can also do with user vars.

Although, I couldn't get shell integration working in Fish shell for some reason.

[wez]

FWIW, Windows doesn't have a proper concept of foreground process or job control, so pane:get_foreground_process_info and related functions make an educated but not totally reliable guess, as is mentioned there in the docs.

I'd recommend emitting a user-var from the nvim code for a more reliable way to communicate this sort of state with the wezterm gui; linking to a related thread here:

• https://github.com/wez/wezterm/discussions/3648

[mrjones2014]

@jeeeem please take a look at the latest smart-splits.nvim docs and let us know if this is still an issue. smart-splits.nvim now sets a Wezterm user variable IS_NVIM=true and clears it when nvim exits. You can use this for your Wezterm keymaps instead of checking the process name.

You will need to update your Wezterm keymaps as per: https://github.com/mrjones2014/smart-splits.nvim#wezterm

[RazaGR]

@mrjones2014 I tried the latest smart-splits.nvim Lazy.nvim, while its working great switching between neovim and panes, I can't get it to work moving to Neo-tree pane direction CTL-h.

[mrjones2014]

Alright, in that case it sounds like a plugin issue at this point. Please open an issue in the smart-splits.nvim repo with a minimal init.lua so that we can let Wez close this issue.

[github-actions[bot]]

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.