Plugin doesn't unbind keys after long uptime

[askedrelic]

Moving this from here: tmux/tmux#362

I've noticed after leaving a tmux session open for a long time (10 days apparently), when pasting, it scrambles the pasted content. Restarting the tmux server fixes it, so it's not that bad. It's happened several times to me over the last few months, but I finally have time to record all the details.

Here is a quick example of what happens when trying to paste the alphabet. It appears like for short pasted content, it's only visually altered?

$ abcdefghijklmoprstuvwxz nqy
-bash: abcdefghijklmoprstuvwxz: command not found

The idea is this caused from this plungin:

The culprit is almost definitely tmux-copycat. It binds n, q, and y in the root table (i.e. intercepts them without needing prefix) and I noticed sometimes it doesn't clear those bindings. As a result, pressing those keys takes longer than other keys because they run a shell script resulting in what you described.

[wilywampa]

I made a pull request that might help a little: #100

It will still happen on occasion because the method of checking if any windows are in copycat mode is necessarily imperfect. If one exists copy mode by means other than the keybindings listed in scripts/helpers.c, for example by scrolling down until tmux exits copy mode or maybe by copying to a named buffer, the counter will not be decremented and the problem will occur.

There's a command unbind_all_bindings in scripts/copycat_mode_quit.sh that you can call to cancel the bindings if this happens. Still annoying, but better than restarting the server.

FWIW, I don't think it's related to uptime and it's not just visual, or even just caused by pasting. I first noticed it because I kept having "no" being changed to "on" while typing quickly.

[virusdave]

Any update on an actual fix for this? I've been stuck in this mode for >6 months, and was questioning my sanity until i finally stumbled upon this bug (via the tmux#548).