search

christoomey / vim-tmux-navigator

Seamless navigation between tmux panes and vim splits
MIT License
5.07k stars 319 forks source link

Suggestion: Improved is_vim performance #376

Closed b0o closed 4 months ago

b0o commented 4 months ago

The recommended tmux configuration for navigating panes is slower than it needs to be, because it's checking if a pane contains vim at the moment you press the keybinding to switch panes.

This leads to a small but perceivable delay (on my system around 50ms), which seems to worsen as there are more processes running on the host. It's most noticeable if you try comparing the time it takes to switch between windows in vim inside vs outside of tmux.

I wrote a script for tmux that runs in the background and periodically checks which panes contain vim and sets a pane-local option. Then, when you hit the keybinding to switch panes, tmux only needs to check for this option to determine what to do, rather than shelling out to ps and grep. With this approach, there is virtually no lag when switching panes.

The script: https://github.com/b0o/tmux-conf/blob/main/navi.tmux

bind-key -n C-h if -F "#{@navi-state}" "send-keys C-h" "select-pane -LZ"
bind-key -n C-j if -F "#{@navi-state}" "send-keys C-j" "select-pane -DZ"
bind-key -n C-k if -F "#{@navi-state}" "send-keys C-k" "select-pane -UZ"
bind-key -n C-l if -F "#{@navi-state}" "send-keys C-l" "select-pane -RZ"

# at the end of your conf
run-shell "$XDG_CONFIG_HOME/tmux/navi.tmux"

I started a similar discussion at https://github.com/mrjones2014/smart-splits.nvim/discussions/154 where the author suggested just setting the pane-local option directly from the plugin, rather than needing a BG script. I think that's a good idea, but the downside is it restricts this approach to only work when the plugin is installed and loaded.

What do you think about this?

christoomey commented 4 months ago

Hi @b0o, thanks for sharing this!

Ultimately my goal is stability and simplicity with maintaining this plugin, so while I'm sure there is a performance gain to be had here, the idea of adding more complexity to the core process detection logic (at least in the default recommended configuration), is not something I'm looking to do.

That said, the nice thing about this plugin is that it's somewhat modular, so folks could easily swap to your implementation if they're noticing a lag and interested in improving the performance.

Again, thanks for sending this along, and providing detail in this issue. I'm going to close this based on the points above, but I want to be clear that this is a really cool optimization 🙂