'pipenv shell' breaks vim-tmux-navigator motions inside vim running under tmux

I have a large tmux pane across the top 75% of the window, with two small ones split 50/50 below, each running zsh. Vim is running in the large pane and has two vertically-split windows. vim-tmux-navigator lets me use <c-h/j/k/l> to navigate the vim windows and zsh panes using the same keystrokes (e.g. from the left Vim window, <c-l> switches to the right Vim window, <c-j> switches to the zsh pane below and <c-k> switches back to the previous Vim window)

Describe your environment

1. OS Type: macOS 10.13.3
2. Python version: 3.5.2 (base version), 3.6.4 (inside pipenv shell)
3. Pipenv version: 9.0.1
4. Vim: VIM - Vi IMproved 8.0 / macOS version / Included patches: 1-1450
5. zsh: 5.4.2
6. iTerm2 build 3.1.5
7. vim-tmux-navigator

Expected result

<c-h/j/k/l> moves seamlessly between Vim windows in the top tmux pane and the zsh sessions in the lower two panes

Actual result

With Vim running inside the pipenv shell the <c-h/j/k/l> shortcuts don’t work inside Vim - only - but do work to navigate between Vim and the zsh panes. Per the previous example, <c-h/l> appear to do nothing, but <c-j/k> moves between Vim and the zsh panes. The full :TmuxNavigateLeft/:TmuxNavigateRight commands continue to work and the keyboard mappings in Vim haven’t been changed.

Closing the lower zsh splits doesn’t restore the original Vim keyboard shortcut behaviour.

Steps to replicate

cd new/empty/dir
pipenv shell
vim foo
[inside vim] :vsplit bar
<c-h>/<c-l> do nothing
:qa 
exit
vim foo
[inside vim] :vsplit bar
<c-h>/<c-l> move to left/right vim windows

Comparing the output of env between the original shell and the pipenv shell doesn’t show anything obvious - $TERM, $SHELL, $TMUX, $TERM_SESSION are all identical - the only notable changes are to $PATH, $PKG_CONFIG_PATH and $GVM_PATH_BACKUP and none of those seem incriminating

[RobbieClarken]

I ran into the same problem on Ubuntu with Pipenv 10.1.0.

I tracked the problem down to the command being run to determine if vim is open in the active tmux pane:

is_vim="ps -o state= -o comm= -t '#{pane_tty}' \
    | grep -iqE '^[^TXZ ]+ +(\\S+\\/)?g?(view|n?vim?x?)(diff)?$'

You can see the problem by running the following from a tmux pane with vim open:

:run-shell "ps -o state= -o comm= -t '#{pane_tty}'"

If pipenv shell is not activated, the output is:

S bash
S vim

if pipenv shell is activated, the output is:

S bash
S pipenv

So the grep that looks for vim is failing.

I’ve worked around this problem by creating a script called tmux-check-if-vim with the following body:

#!/bin/bash
pane_tty=$1
pipenv_pid=$(pgrep -t ${pane_tty/\/dev\/} pipenv)
if [[ $? == 0 ]]; then
  ps -o state=,comm= -p $(pstree -p $pipenv_pid | grep -Po '\(\d+\)' | tr -d '()')
else
  ps -o state=,comm= -t $pane_tty
fi | grep -qP '^[^TXZ] (view|vim)$'

and replacing the is_vim variable in ~/.tmux.conf with

is_vim="tmux-check-if-vim #{pane_tty}" 

The script first looks for a pipenv process running in the active pane. If it finds one, it looks for vim running as a descendant process of pipenv. Otherwise it looks for vim as a top-level process running in the pane as per normal.

Note the grep I do to look for vim-like programs is less comprehensive than the one suggested by vim-tmux-navigator. In particular, it doesn’t try to catch nvim, gvim, vimx, etc. This shouldn’t be difficult to add.

Also, I have only tested on Linux so it is quite likely it won’t work out of the box on macOS if grep, ps, pgrep or pstree behave differently.

My system configuration is:

OS Type: Ubuntu 17.10 Python: 3.6.3 Pipenv: 10.1.0 tmux: 2.5 vim: 8.0 bash: 4.4.12

[mikeboiko]

I was getting some lag issues from running a bash script as suggested by @RobbieClarken . I solved the pipenv problem by simply adding “pipenv” into the regular expression like so:

is_vim="ps -o state= -o comm= -t '#{pane_tty}' \
| grep -iqE '^[^TXZ ]+ +(\\S+\\/)?g?(view|n?vim?x?|pipenv)(diff)?$'"

I haven’t fully tested what adverse effects this could cause with non-vim uses of pipenv, but seems to do the trick for the time being with no lag!