Switching out of Vim slow

[SeeThruHead]

It takes roughly 2.5 seconds to switch from vim to another tmux pane. Switching inside vim or between non vim tmux panes is instant. I'm not sure if it was happening when I initially installed this plugin.

Would you happen to know what is causing it? Or maybe what setting I messed with that caused this?

[jottr]

I am observing a similar issue. Although it is not as slow as 2.5 seconds, it is noticeably slower to switch from a pane with vim inside, to another pane without vim.

This makes working with vim and tmux splits feel extremely sluggish and annoying.

[SeeThruHead]

I can't recall whether or not this was happening when i first installed this plugin. Unfortunately I don't have the time right now to remove plugins and do testing.

[christoomey]

Hello @jottr, @SeeThruHead,

The only thing I can think of is if you have other mappings in Vim like <C-h>x where x is any other key. You can check this by running the following commands in vim:

:nmap <C-h>
:nmap <C-j>
:nmap <C-k>
:nmap <C-l>

You should see the following:

n  <C-H>       * :TmuxNavigateLeft<CR>

If you see any other lines it means you have another mapping in that keyspace, and Vim will wait after you press <C-k> to see if you are going to type the other key for the additional mapping.

[SeeThruHead]

Thanks Chris.

I wish it were that, but there isn't anything but the expected output. Mouse clicking into a separate pane doesn't have any delay. So I'm pretty sure vim is waiting for something before executing the tmux command.

[jottr]

Same for me, I have not mapped <C-h> and j,k,l to anything else.
:nmap <C-h> returns the desired output. Same goes for all other navigation keys, obviously.

[montlebalm]

I'm having the same issue and also do not have <c-h> mapped to anything else. This has been an issue since I started using this plugin months ago, so I don't think it was introduced recently.

[christoomey]

@montlebalm @jottr @SeeThruHead, can you confirm if this behavior is present on all mappings or just specific ones? Also, could you add you terminal, shell, tmux, and vim versions?

[SeeThruHead]

Hi Chris, it's the same for all mappings.

• iTerm 2.1
• fish, version 2.1.2-1255-g9c007d1
• tmux 1.9a
• VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 21 2015 17:53:31) MacOS X (unix) version Installed via brew install macvim --override-system-vim

[montlebalm]

@christoomey slow on all directions moving out of vim into tmux. Here's what I'm running:

• mvim (cli): 7.4
• tmux: 2.0
• iTerm: 2.1
• zsh: 5.0.5

In case it helps, here's my full vim version:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled May  2 2015 21:22:51)
MacOS X (unix) version
Included patches: 1-712
Compiled by Homebrew
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_binary
+arabic          +find_in_path    -mouse_sysmouse  +tag_old_static
+autocmd         +float           +mouse_urxvt     -tag_any_white
+balloon_eval    +folding         +mouse_xterm     +tcl
+browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     +fullscreen      -mzscheme        +textobjects
+cindent         -gettext         +netbeans_intg   +title
+clientserver    -hangul_input    +odbeditor       +toolbar
+clipboard       +iconv           +path_extra      +transparency
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
+farsi           +mouse_netterm   +syntax

[christoomey]

It looks as though everyone is using the most recent if-shell variant of the tmux mappings. Would one of you mind trying out the original inline grep version for comparison?

https://github.com/christoomey/vim-tmux-navigator/blob/28ce8e70d54efee91e24d9184c152a17c108f53e/README.mkd#tmux

# Smart pane switching with awareness of vim splits
bind -n C-h run "(tmux display-message -p '#{pane_current_command}' | grep -iqE '(^|\/)g?(view|n?vim?)(diff)?$' && tmux send-keys C-h) || tmux select-pane -L"
bind -n C-j run "(tmux display-message -p '#{pane_current_command}' | grep -iqE '(^|\/)g?(view|n?vim?)(diff)?$' && tmux send-keys C-j) || tmux select-pane -D"
bind -n C-k run "(tmux display-message -p '#{pane_current_command}' | grep -iqE '(^|\/)g?(view|n?vim?)(diff)?$' && tmux send-keys C-k) || tmux select-pane -U"
bind -n C-l run "(tmux display-message -p '#{pane_current_command}' | grep -iqE '(^|\/)g?(view|n?vim?)(diff)?$' && tmux send-keys C-l) || tmux select-pane -R"
bind -n C-\ run "(tmux display-message -p '#{pane_current_command}' | grep -iqE '(^|\/)g?(view|n?vim?)(diff)?$' && tmux send-keys 'C-\\') || tmux select-pane -l"

[SeeThruHead]

No change with those bindings.

[christoomey]

Perhaps we can isolate it. Can someone try the following:

Test From Send-keys Down

1. Open vim and a shell in tmux panes (2 panes total), vim on left, shell on right
2. Focus the Vim pane.
3. Run the following via the tmux command prompt (accessed with <prefix>: key binding) send-keys C-l

Test From Vim

1. Same layout as above, tmux focus on vim pane
2. Run :TmuxNavigateRight

---

Depending on which combination of these trigger the same slowness we might be able to pin something down

[montlebalm]

@christoomey as far as I can tell they're equally slow. Each waits ~1 second to switch.

[montlebalm]

fyi, I have the same problem using Terminal.app in lieu of iTerm.

[SeeThruHead]

@christoomey identical

[christoomey]

At this point I am just about out of ideas. It seems like it is in the plugin code, but I'm not sure where. The relevant function can be found here. If anyone wants to try testing aspects of it to see if they can zero in on the timing issue, that'd be great.

I'll keep this issue open to see if some kind soul might come through with a pointer.

[jottr]

@christoomey maybe you could also ask on #vim and #tmux on freenode? It's possible that someone with a lot of experience in vimscript might be able to help debugging the issue.

[montlebalm]

@christoomey you might have already done this, but I figured it would be helpful to have a profile of the slowness. Here's what it looks like on my machine:

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    1   0.570801   0.000057  <SNR>24_TmuxWinCmd()
    1   0.570735   0.000190  <SNR>24_TmuxAwareNavigate()
    2   0.000459   0.000095  <SNR>55_OnCursorHold()
    2   0.000180   0.000088  <SNR>55_OnFileReadyToParse()
    2   0.000117             <SNR>55_AllowedToCompleteInCurrentFile()
    2   0.000067             <SNR>55_SetUpCompleteopt()
    2   0.000066   0.000048  <SNR>55_UpdateDiagnosticNotifications()
    2   0.000026             <SNR>55_SetUpYcmChangedTick()
    2   0.000018             <SNR>55_DiagnosticUiSupportedForCurrentFiletype()
    1   0.000009             <SNR>24_InTmuxSession()

[montlebalm]

Interesting. I just noticed that running :!tmux select-pane -R from vim is significantly slower than :select-pane -R from tmux. Could this be related to terminal start time?

[SeeThruHead]

@montlebalm that definitely feels like the same delay.

[montlebalm]

I eviscerated my ".zshenv" and the pane switching delay went away. It looks like that might be a decent bandaid until we can find another suitable solution.

[christoomey]

@montlebalm Awesome work! Both of those functions do shell out, so that makes sense. You should be able to move the offending zsh config from zshenv (loaded by all shells) into zshrc (loaded only by login shells) if I understand correctly. Vim does not use a login shell, so that should fix the slowdown, but still keep your zsh configs for your normal shell sessions rather than having to remove entirely.

[SeeThruHead]

.vimrc : set shell=/bin/bash\ -i is what is working for me (i'm using fish an I don't think it has a non-login shell, or if it does it also has some delay when loading)

[jottr]

The above worked for me as well. Great work @SeeThruHead.

[christoomey]

Sounds like we've narrowed this down to a shell startup time issue. I'm planning to close and update the readme to add a note about this. Any concerns @jottr @SeeThruHead @montlebalm ?

[SeeThruHead]

none here

[montlebalm]

@christoomey sounds like the best option

[christoomey]

Created a PR for the readme updates. https://github.com/christoomey/vim-tmux-navigator/pull/75

I feel like the language is a bit lacking / might be unclear to a user. Any recommendations on how to improve?

[christoomey]

I've merged the update to the readme with @montlebalm's updated text (thanks!). Thanks all for the help tracking this down. Closing now as I believe this covers the issue, but feel free to comment or re-open if there seems to be another source of slowness.

[krzkrzkrz]

Using iTerm. I have /usr/local/bin/fish in /etc/shells. I'm using the Fish shell by default. I set it using:

chsh -s /usr/local/bin/fish

I have set shell=/bin/bash\ -i in .vimrc. The delay is still there.

In Vim. When I type :echo $SHELL, I get /usr/local/bin/fish. Is Vim still using the Fish shell even though I explicitly set it not to?

Does it matter where in .vimrc, set shell=/bin/bash\ -i is placed?

Am I missing out on something?

[SeeThruHead]

if you do :sh does it put you in bash? and when in bash does echo $SHELL give you back fish. That's what I have.

[krzkrzkrz]

Yeap it does. :sh puts me in bash. echo $SHELL in bash, returns: /usr/local/bin/fish

[SeeThruHead]

Do you have a lot in your bashrc? If so try moving that to your bash_profile

[krzkrzkrz]

WOW! I was experimenting and commented out everything in .bashrc. The problem went away. No delay. Definitely something in there. Will update here when I find out

[SeeThruHead]

Yeah you'll want to move your personal setting into bash_profile. Which is what's loaded for your login shell. Bashrc can be pretty bare. It will reduce the shell startup time.

[krzkrzkrz]

source "$HOME/.vim/bundle/gruvbox/gruvbox_256palette.sh" and source ~/.nvm/nvm.sh in .bashrc were causing the delays. Should I just move these out to .bash_profile?

[krzkrzkrz]

My .bashrc looks like.

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls -G'

export EDITOR='vim'
source ~/.ps1colors

# Gruvbox contains shellscript (default and osx-iterm2 versions), which would overload system default 256-color palette with precise gruvbox colors.
# Make sure this vim plugin is installed first
source "$HOME/.vim/bundle/gruvbox/gruvbox_256palette.sh"

LINE1="\[$bldwht\]┌─\[$txtrst\][\[$bldgrn\]\u@\h\[$txtrst\]][\[$bldblu\]\w\[$txtrst\]]"
LINE2="\[$bldwht\]└─\[$txtrst\][ "
PS1="$LINE1\n$LINE2"

export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*

# export NVM_DIR="$HOME/.nvm"
# [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm

source ~/.nvm/nvm.sh

### Added by the Heroku Toolbelt
export PATH="/usr/local/heroku/bin:$PATH"

What do you think I can move over?

[SeeThruHead]

I would say you might be able to move everything over. At least give it a try and move things back if you need them in a non login shell. As issues pop up. See if that fixes the slow shell startup.

[seatownrocks]

I also lag switching from neovim pane to any other pane and I use fish shell so I added:

set shell=/bin/bash\ -i to ~/.config/nvim/init.vim

This eliminates the lag but after switching out then back to an nvim pane, if I then navigate up or down with k or j nvim appears to crash as I am dumped to a shell prompt.

You must leave an nvim pane first then return in order for j or k to crash nvim. This does not occur on first entry to an nvim pane. This can be verified with a tmuxinator script that sets up two tmux panes, the first a shell and the second an nvim pane, and starts the user in the shell pane. Switching to nvim for the first time then pressing j or k does not crash nvim, however then switching away and back to nvim and then pressing j or k does crash nvim. Tmuxinator script:

https://gist.github.com/seatownrocks/2b5d136b79ff907ee384

Note that I use and keys to switch panes instead of the default vim-tmux-navigator keys.

My setup: NVIM 0.1.2-dev fish, version 2.0.0 tmux-2.1.tar.gz tmuxinator 0.7.1

[AmeerTaweel]

.vimrc : set shell=/bin/bash\ -i is what is working for me (i'm using fish an I don't think it has a non-login shell, or if it does it also has some delay when loading)

Thank you @SeeThruHead for your solution. It really helped me with the speed issue.

I am using:

• TMUX v3.1c
• VIM v8.2
• Fish Shell 3.1.2

Navigation between vim panes was extremely slow. But when I used:

set shell=/bin/bash\ -i

It became fast again. However, if I switch between a vim pane and a tmux pane, the whole window is closed. So I changed the line to:

set shell=/bin/bash

And now it works fine, it's still fast, but it does not close the window when I go from vim to tmux. I don't even know that the -i flag does, but removing it solved the problem for me. I just want to put this here so it helps anyone who encounters the same problem.