1

I am having this issue for about 2 years now (since I started to use tmux in Summer 2018) and I have not found a solution to this problem. Any help is greatly appreciated!

The copy functionality of tmux is slow. Often times when I copy using mouse selection, and then I paste in the terminal it almost always pastes what I thought was in the clipboard previously, it never copied the current mouse over selection into the clipboard. I have to select and then wait for a bit (usually a second or so).

I am so used to the copy current mouse selection from linux, iTerm2 on macOS and they are blazingly fast, I never have to think about or wait for the selection to be copied.

This causes problems because sometimes my clipboard has sentences and when I mouse over let's say a dir path/filename/git commit hash, etc. and paste in the terminal thinking that a dir path/filename/git commit hash will be pasted, here comes a barrage of sentences.

I have tried a few ways to address this problem none of them to my satisfaction.

  1. I tried to print a message after the copy was done:

    bind -T copy-mode-vi Tab send -X copy-pipe "reattach-to-user-namespace pbcopy"\; display-message "copied to system clipboard"
    
  2. I saw the mistake I was doing with calling reattach-to-use-namespace every time on selection, so instead, I started tmux only once with this program:

    set-option -g default-command "reattach-to-user-namespace -l bash"
    bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe "pbcopy" \; display-message "copied to system clipboard"
    
  3. Later I switched to tmux-plugins/tmux-sensible which starts tmux with reattach-to-user-namespace.

  4. And now a few weeks back I disabled all the bind-key copy configuration and switched to tmux-plugins/tmux-yank. I prefer the tmux-yank configuration better than what I had. But the slowness or delay in copying still persists, I am often pasting the wrong information, thinking the mouse selection is copied into the system clipboard.

I also running updated software as much as possible, hoping to see some improvements. The issue is I do not where the problem is to debug further. Is the slowness in tmux or reattach-to-user-namespace or Alacritty or OS X.

I tried switching back to iTerm2 because this issue was getting annoying but after using Alacritty, iTerm2 is sluggish and slow, as I am streaming a lot logs in the terminal for debugging. And unfortunately Alacritty does not support multi-window mode or tabs at the moment.

Alacritty+tmux on macOS is the perfect solution at the moment for me, except for this once annoyance with the slowness in copy.

I am running:

I ran into this https://github.com/alacritty/copypasta, I want to give this a try and see if this improves the situation.

And just for writing this question, I pasted the wrong info many times and had to go back and wait for the copy to properly finish.

1 Answer 1

1

reattach-to-user-namespace should not be necessary anymore, you can try without it entirely.

There is little tmux could be doing to make copying a small amount of text take a couple of seconds so probably this is pbcopy.

If your terminal supports OSC 52 (iTerm2 does, I'm not certain about alacritty), you could use it instead of pbcopy - see https://github.com/tmux/tmux/wiki/Clipboard.

If you are not using OSC 52, make sure to turn set-clipboard off.

9
  • Hi @nicholas-marriott, thanks for your response! So alacritty does support OSC 52, github.com/alacritty/alacritty/blob/master/CHANGELOG.md#fixed-2. I have done the following to make sure nothing but the internal tmux copy to system clipboard is being executed: - uninstalled reattach-to-user-namespace - disabled tmux-sensible plugin (which turns on reattach-to-user-namespace for macOS) - set -s set-clipboard on - disable alacritty's save to clipboard option: alacritty.yml: ``` selection: save_to_clipboard: false ``` The copy is working fine from tmux on select.
    – krafts
    May 27, 2020 at 18:58
  • I am unable format the response correctly. I am testing the changes I made and will report back in a day or two.
    – krafts
    May 27, 2020 at 19:02
  • I have also disabled tmux-yank plugin and just relying on set-clipboard. Things are working so far.
    – krafts
    May 27, 2020 at 19:15
  • Okay so after much use, I have noticed that the issue is not with tmux being slow but my behavior on how I use the copy on selection. I am hardwired to how iterm2 does the copy, it copies as the selection happens. On tmux, the copy happens when the left mouse button is released with the binding, MouseDragEnd1Pane. I am so used to this behavior that I keep pasting the selecting ever before releasing the mouse and hence the old value of the clipboard keeps being pasted. Which mistakenly I thought was slowness in the tmux copy.
    – krafts
    Jun 2, 2020 at 18:02
  • I have found some documentation on the wiki about MouseDragEnd1Pane github.com/tmux/tmux/wiki/…. And an issue that discusses this behavior, github.com/tmux/tmux/issues/1804. I was unsuccessful in getting MouseDrag1Pane to bind to copy, it breaks the selection of text when scrolled back in the buffer. But over all I have more insight into what is happening! Thank you @nicholas-marriott!!
    – krafts
    Jun 2, 2020 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.