The change panels mappings freeze my terminal
renan-eccel opened this issue · 19 comments
I am using ITerm2 3.4.8 and tmux 3.2.
Yesterday everything was working right. I was using a vim and tmux together and the mappings are working as usual.
However, when I opened the shell where I stopped working, the <ctrl+h> mapping froze my shell.
Since this, all the 4 mappings to change panels are doing the same thing.
Hi @renan-eccel, did you check into any of the troubleshooting tips in the readme? Hard to say what might be happening without knowing a bit more.
yes, I checked it.
vim -> tmux works fine, tmux -> tmux and tmux -> vim is the problem.
I also checked some issues, but nothing seems to be the same problem.
:(
Same here. Enabling the plugin freezes the terminal.
Hi @sfc-gh-ssudakovich, any recent updates to your setup that might be tied to this? Updating tmux, this plugin, tmux config, shell, etc? Also, when you say
Enabling the plugin freezes the terminal.
Can you provide any more detail? By "enabling" do you mean just adding the config to tmux / vim setup, or are your referring to using it with the C-hjkl mappings?
And when you say "freezes", the thing that comes to mind is Ctrl-s / Ctrl-q freezing. Does that correctly describe what's happening, or is it something else?
Sorry, I should have been more clear.
- I recently updated to tmux 3.2a, i started noticing the issue right after that
- When I say enable, I mean add
set -g @plugin 'christoomey/vim-tmux-navigator'to.tmux.conf, so load the plugin via tpm - when I say "freeze" I mean I can not interact with tmux at all for good 30-60 secs
- the only time it "freezes" is when I move from tmux to vim (or other way around); no issue when window switching between tmux panes or within vim
Hi @sfc-gh-ssudakovich thanks for the additional notes. Sounds like something in 3.2a is not happy with the plugin.
Just to confirm, does the 30-60 seconds of freezing happen when you first activate tmux, or only when using the C-h|j|k|l navigation hotkeys?
Also, do you happen to know what version you were on prior to upgrading to tmux 3.2a? I'm wondering if can narrow down the problem release.
I am experiencing exactly the same issue and here is my setup and symptoms.
When I comment out (disable) set -g @plugin 'christoomey/vim-tmux-navigator' line from my tmux config, there is no such delay when C-hjkl is pressed.
I was using tmux@3.2a so I downgraded it to 3.2 just to see if it's an issue with 3.2a but I still experience the same delay with 3.2.
The terminal freezes for about 43 seconds for me as shown below in a gif. After the freeze, everything I type during the frozen period shows up in the pane that was supposed to have the cursor when C-hjkl was pressed. Note that if navigation key is pressed with the prefix, for example C-a h and C-a l, it navigates just fine without delay.
Same is happening to me. I don't remember modifying anything lately. While checking what was going on I reinstalled tmux and the plugins with the same results (iirc I had a HEAD version from april, and now I have the latest).
This happens also outside vim when switching panels. For me it also took around 40-42 seconds. If I directly map the key with bind-key -n c-L select-pane -R, the change of panel works normally.
I have started tmux with -vv and the server file grows quite fast (about 1MB every 5 sec). That doesn't look normal to me, but I don't know if that's expected.
I'm using fish and alacritty in mac, but same happens with terminal + zsh.
The following command also takes around 40 sec to display the message and freezes tmux completely:
if-shell "ps -o state= -o comm -t '/dev/ttys002'" "display-message 'hi tmux'"
If I run it from the terminal (same command, tmux if-shell ..) tmux doesn't freeze completely but I don't get a new prompt until ~40 sec pass.
Hi folks, thanks to everyone for sharing the info thus far. I've opened an issue against tmux proper as I believe this discussion is pointing to a regression on that side of things (although I'd happily accept that I'm doing something wrong in the plugin). I'll update here as I learn anything, and please feel free to continue sharing anything you find.
More data points:
run-shell "ps -o state= -o comm" - Without delay
run-shell "ps -o state= -o comm -t '/dev/ttys000'" - With delay
I suspect this has to do with tty option of ps command. When I run ps -o state= -o comm -t '/dev/ttys004' on my zsh terminal without tmux, it stalls as well with similar amount of delay until the output is displayed. Not sure why or how to dig deeper though.
Hey folks, I'm not sure when I'll be able to get around to it, but if anyone's up for trying to dig in further, tmux has notes on the issue template related to debugging / grabbing additional info: https://github.com/tmux/tmux/blob/master/.github/CONTRIBUTING.md. If anyone wanted to grab than and either share here or open a new issue on https://github.com/tmux/tmux, that would be great.
Temporary workaround:
Looking through opened pull requests, I found #248, which uses grep instead of -t option for ps and somehow this doesn't freeze the terminal. For now, I made a small tweak with this PR's change and the navigation works without delay for me. The main change was is_vim="ps -a | grep -qE '#{s|/dev/||:pane_tty}''.*(n?)vim'".
Weirdly, if only #{:pane_tty} is used without substitute command, it still hangs.
I can confirm that modifying the is_vim check in my conf also appears to fix my issue.
For context I am on
- NeoVim 0.5.0
- Tmux 3.2a
- MacOs 11.4
- Alacritty 0.8.0
I change mine to the following:
is_vim="ps -o state=,tty=,comm= | grep -iqE '^[^TXZ ]+ +#{s|/dev/||:pane_tty}\s+(\\S+\\/)?g?(view|n?vim?x?)(diff)?$'"
same issue..didn't update anything. everything starts freezing as soon as I open a new pane. can confirm that @idonchu and @hurricanehrndz fix worked for me
Thanks all for the discussion and help here, and thanks to @kidonchu for providing the new snippet. I've tested and the updated snippet does seem to work for me, so I've opened #300 to update the documentation.
My only concern is that I'm running a recent version of tmux, but I'd like to make sure this works for previous versions as well. Ideally we can avoid wrapping the is_vim in a version check, but might end up needing to. @kidonchu do you know if the is_vim snippet you shared uses any non-backwards compatible features?
I also experienced current is_vim too laggy. None of it worked for me.
Here's alternative is_vim using pgrep.
brew install proctools # required for mac
is_vim="pgrep -t #{pane_tty} nvim"
EDIT: I'm still experiencing wierd random hang in mac.
I don't think is_vim logic is the real problem. But still the command above is generally faster than others.
don't shoot, just asking ;)
why not use pane_current_command ?