Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

tmux 2.1 update breaks keyboard mappings #45413

Closed
patspam opened this issue Oct 28, 2015 · 10 comments
Closed

tmux 2.1 update breaks keyboard mappings #45413

patspam opened this issue Oct 28, 2015 · 10 comments

Comments

@patspam
Copy link

patspam commented Oct 28, 2015

I use iTerm + tmux, with "send hex code" keyboard shortcuts mapped to switch prev/next pane.

eg. I have Option+h mapped to send "0x01 0x70" and Option+l mapped to "0x01 0x6E". This allows rapid switching between panes with hjkl direction keys.

Since updating to tmux 2.1, this is partially broken. Hitting Option+h the first time prints "p" into the console. Hitting it a second time successfully fires the sequence, triggering pane switching. Ditto for all my other mappings.

I can still successfully use this mappings when SSH'ed into other remote servers (using iTerm locally and tmux remotely), which leads me to conclude that the issue is with my local Mac's tmux version.

@dunn
Copy link
Contributor

dunn commented Oct 28, 2015

I know some defaults were changed in this release, so this might not be Homebrew-specific. Can you check if this happens with a tmux built outside Homebrew?

@benjaminwhite
Copy link
Contributor

I don't know if this is an appropriate place to offer alternatives, so please forgive me if this is a faux pas. There's a setting in iTerm which allows the option key to be used as Meta. You can choose either Meta or Esc+ (they act mostly the same).

Then in tmux, you can use bind -n to bind key combinations without needing to use your prefix key. So all you have to do is bind Meta-{h,j,k,l} in tmux to achieve the same effect, without any hex code hacking:

bind -n M-h select-pane -L
bind -n M-j select-pane -D
bind -n M-k select-pane -U
bind -n M-l select-pane -R

@patspam
Copy link
Author

patspam commented Oct 30, 2015

@dunn: I haven't had time to build tmux from source, but when I manually copied the old version (opt/homebrew/Cellar/tmux/2.0) from another OS X machine and launched it directly from the bin/ folder, the issue went away.

That's with an up to date tmux with all other packages upgraded to current latest versions, so seems like a pretty strong indication that the issue is specific to the tmux package.

@tt
Copy link
Contributor

tt commented Oct 30, 2015

See tmux/tmux#159. Running set -g assume-paste-time 0 resolved the issue for me.

@dunn
Copy link
Contributor

dunn commented Oct 31, 2015

If the developers can be convinced to change the default configuration, we'll be happy to backport the change!

@MikeMcQuaid
Copy link
Member

If the developers can be convinced to change the default configuration, we'll be happy to backport the change!

Agreed 👍

@patspam
Copy link
Author

patspam commented Nov 3, 2015

Thanks @tt. Adding set -g assume-paste-time 0 to my ~/.tmux.conf solved it.

@Tuurlijk
Copy link

Tuurlijk commented Nov 4, 2015

Hooray!

@tonekk
Copy link

tonekk commented Jan 12, 2016

Thanks so much, just invested another 4 hours into my dotfiles just to have the new keybindings not working on my other machine.
Thanks @tt 👍

@MikeMcQuaid
Copy link
Member

This is an upstream issue. We'll consider a PR to improve our configuration but it's not Homebrew's bug so closing.

@Homebrew Homebrew locked and limited conversation to collaborators Jul 10, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants