Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Characters sent from terminal are garbled by tmux in 2.1 #159

Closed
willvousden opened this issue Oct 22, 2015 · 6 comments
Closed

Characters sent from terminal are garbled by tmux in 2.1 #159

willvousden opened this issue Oct 22, 2015 · 6 comments

Comments

@willvousden
Copy link

My terminal emulator (ITerm2) has key mappings that character sequences, to make certain tmux actions a bit easier (e.g. cycling through windows). For example, I have one that sends 0x06 0x70 (corresponding to a C-f p binding in tmux; my prefix is C-f). (This is described here).

These worked fine in 2.0, but now tmux seems to be capturing the sequence in the wrong order, so that it comes through as p C-f. I can't quite work out a pattern to when it does and doesn't work, but it seems to be something to do with the timing of how they're sent.

For example, if I create separate mappings in my terminal emulator for C-f and p and press them in sequence, it works fine.

@nicm
Copy link
Member

nicm commented Oct 22, 2015

turn down assume-paste-time

@nicm nicm closed this as completed Oct 22, 2015
@willvousden
Copy link
Author

Thanks, I wasn't aware of that option.

Still, its default value hasn't changed from 1ms between 2.0 and 2.1 (and the key mappings still works with 1ms on remote machines running 2.0). Why has tmux's behaviour changed?

@gusgard
Copy link

gusgard commented Nov 3, 2015

+1

@henrik
Copy link

henrik commented Dec 22, 2015

To make things more explicit for the next person: add this to your ~/.tmux.conf:

set -g assume-paste-time 0

@ifyouseewendy
Copy link

+1

ifyouseewendy added a commit to ifyouseewendy/dotfiles that referenced this issue Jan 8, 2016
@lock
Copy link

lock bot commented Feb 16, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

5 participants