tmux-copycat: tmux-copycat slow on my machine

I just installed this plugin. I saw the screencast and it looks very fast. However, on my machine it takes around 1 second to find a match. Not sure what did I do wrong. Here’s my tmux config:

unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix

# don't rename windows automatically
set-option -g allow-rename off

# allow mouse to scroll
set -g mouse on

# scrolling 1 per line
set -g @scroll-speed-num-lines-per-scroll "1"

# themepack theme
set -g @themepack 'powerline/block/gray'

# We want tmux to support 256 colors and allow itallics
set -g default-terminal 'tmux-256color'
set -as terminal-overrides ',xterm*:Tc:sitm=\E[3m'

# List of plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'tmux-plugins/tmux-copycat'
set -g @plugin 'tmux-plugins/tmux-pain-control'
set -g @plugin 'nhdaly/tmux-better-mouse-mode'
set -g @plugin 'jimeh/tmux-themepack'

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run '~/.tmux/plugins/tpm/tpm'

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 13
  • Comments: 24 (7 by maintainers)

Most upvoted comments

I think this is possible – I’m not sure if maybe @bruno- or someone else had a reason for not doing this, but since the copycat scripts that we bind those keys to check if we are in “copycat mode” and simply do nothing if we’re not, I think it’s safe to simply leave those keys bound at all times.

I’ve updated my fork 1 with that change, so feel free to test it out. It’s still not as snappy as I think I would like it to be but it is still noticably quicker.

On Sun, 03 Nov 2019 at 03:33 PM, Danijar Hafner wrote:

Would it be possible to bind the keys (maybe different ones to avoid conflicts) once during startup rather than every time copy mode is entered?

– You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tmux-plugins/tmux-copycat/issues/129#issuecomment-549191094

What’s the reason for dumping the buffer to a text file before searching it? I’d be happy to help make this faster. The plugin is a great idea but right now unfortunately pretty annoying to use.

I’ve set history-limit as suggested and in a fresh tmux session it takes about 1s to find a match, pressing n takes roughly 350ms to go to next match. Any ideas on how to bring this down?

I did some digging and it looks like the slowness is not caused by dumping the buffer first. By default, copycat dumps up to 9,000,000 scrollback lines, but changing this to even 100 does not make a noticeable difference.

Instead, the bulk of the “lag” comes in the copycat_cancel_bindings function. Whenever copycat mode is started, copycat extends the keybindings it needs for both searching and cancelling. To do this, it parses the output of tmux list-keys for every key to re-bind the key with its extended value.

For copycat_cancel_bindings, this is up to about 11 different keys, in addition to the standard “next” and “prev” keys. You can see this for yourself: if you comment out line 53 of copycat_mode_bindings.sh you’ll see a noticeable improvement in speed (although this will mess things up).

I am not yet sure what the solution is, but at least now we know where the problem is.

I’m having trouble, too; using the set -g history-limit 5000, I used tmux kill-server to start over, then typed tmux to start a new session. I entered echo "http://www.somewebsite.com", then ctl+prefix + ctl + U. It took about three seconds to find the result. This is on a 2018 MBP.

I first began noticing this problem sometime last year; there definitely was a time when it seemed as snappy as in the screencast.

I definitely don’t mean to complain: the only reason this is a problem is because the plugin is incredibly useful. But I’d love it if anyone had any insight into what might be going on: this speed makes it a little hard to rely on the plugin the way I used to.