3 ms·
Yeah. It's not completely tmux's fault -- it's doing what it can, in a terminal emulator -- but it could be smarter. You can make it behave the way it should wi
by ianthehenry 6y ago
Yeah. It's not completely tmux's fault -- it's doing what it can, in a terminal emulator -- but it could be smarter. You can make it behave the way it should with a couple lines in ~/.tmux.conf:
# copy on select
bind-key -T copy-mode-vi MouseDragEnd1Pane send -X copy-pipe-no-clear 'xclip -i -selection primary'
# paste on middle click
bind-key -n MouseDown2Pane { select-pane -t=; run 'tmux set-buffer "$(xclip -o -selection primary)"'; paste-buffer }
(s/xclip/xsel, depending on your system.)
- enriquto 6y agowow, many thanks! This is a neat hack. I wonder why this very natural behaviour is not the default. Your solution is almost perfect. The "paste" code works as expected. But the "copy" code, apart from copying the selection into the clipboard, leaves the tmux pane in an odd state (copy mode) from which you have to exit manually. Would it be possible to bind the command to something that quits copy mode afterwards?
- ianthehenry 6y agoYep! Use copy-pipe-and-cancel instead of copy-pipe-no-clear. I don't think tmux has any, like, OS-aware anything. It can copy to the system clipboard, but only by asking your terminal emulator to copy. To work the way you expect, tmux would need to know to use xclip on Linux and pbcopy/pbpaste on macOS or whatever. Which would be pretty nice! That would be a great, easy feature that would cover ~99% of users. But it seems like it deliberately doesn't want to (?). I'm speculating there.
- enriquto 6y agoThank you very much, you made my day with that!