Tmux for Mere Mortals(zserge.com) |
Tmux for Mere Mortals(zserge.com) |
Workspace at the top level.
- cmd+f1..f9 --> Switch to workspace. - cmd+ctrl+1..9 --> Also switch to workspace (because fkeys are removed and the touchbar is terrible)
Inside each workspace, I use one app in full-screen.
Workspace 1 = IDE Workspace 2 = Terminals Workspace 3 = Browser Workspace 4-9 depends (Spotify, debugger, etc.)
For each app, I switch between tabs using cmd+1...9.
So intuitively, to jump somewhere, cmd+fX to go to the right workspace, then cmd+X to jump to the right tab. For instance, I know my database logs are always in the first tab of my terminal, so: cmd+f2, cmd+1. (On the mac with touchbar, capslock+cmd+2 then cmd+1 (as capslock is bound to ctrl)).
I try to keep this nomenclature everywhere as much as possible. For instance, in Chrome, cmd+1..N jump to the right tab. I configured vscode to do the same. I also disable any transition animations.
For me, this is so intuitive and fast that I have a hard time using 2 monitors as it's faster to jump to the right place than moving my head around or to find the app using cmd+tab.
Finally, where it makes sense, I sub-divide some tabs in tiles. For instance, my "web server tab" is often divided in 4 tiles. Or my IDE is split in various tiles with the files I'm working on.
I used a similar approach back then when I was using stumpwm on linux and tried to bring it back to my mac with as little configuration change as possible. (I only have to map caps lock to ctrl and tweak a few hotkeys to switch workspaces).
Would make a world of difference for apps like Tmux.
Two problems with this. 1) tmux is slower than a window manager like dwm 2) Why not just use dwm
Personally feel rebinding a tool like tmux will bite you down the road.
It's worth learning the defaults, and it's not that hard. They do make some sense.
But who manages THAT many remote sessions? Seems like an upstream problem to me, no?
Heh, well put. Me too. I come to HN looking for... well... "hacks".
It's really clunky, but I went from tmux to just opening new shell windows as needed. I need to be able to resize and scroll, selecting text and copy behavior should be exactly like mac os. Even used a tiling window manager with it for a bit, but it felt pretty restrictive so I went back to just using the cursor to move things around.
> You can't have it all with the mouse no matter your settings
> so I went back to just using the cursor to move things around.
These tools (vim, tmux, etc.) work great for mouseless setups. If you can get comfortable with a 100% keyboard control paradigm, it might work for you. I realize this might not be what you want, but if the statement "spend less time moving your hand between keyboard and mouse" resonates, it's worth revisiting.
I don't think this is correct; it's just that it's not trivial to get things working well. As you say, it depends on using an up-to-date version of tmux (and sadly, you often can't run a config made for a new version with an older version of tmux). And you'll need your terminal to be up to the task (eg. iTerm2 on macOS; not sure what the best thing on Linux would be).
This config shows some useful mouse settings, along with transparent integration with system clipboard via Clipper (even when running tmux on a remote host):
https://github.com/wincent/wincent/blob/81e4b5dc180dd22d8b47...
But like I said, getting it all working nicely requires a bit of work, especially if you want things to work uniformly across Vim, tmux and the shell. Once you've got it all working though, it's great. I can scroll with trackpad or mouse wheel inside and outside of Vim, click or drag to select text (and double-click to select words, triple-click to select lines) both inside and outside of Vim, I can drag tmux or Vim splits etc.
Having sad that, I rarely need or want to take my hands off the keyboard when in the terminal nowadays.
Recently I have been a big fan of tmux+Alacritty on linux.
Doesn't this kinda defeat the point of Vim? I turned on vim bindings and went through an excruciating learning process just to keep my hands on the keyboard. Moving between keyboard and mouse or trackpad was causing significant wrist issues.
As much as I love tmux, I wonder what would it take that the program respects the usual copy-paste conventions like all the rest of X programs. You need to do two things, that are apparently impossible when tmux has "mouse enabled":
1. select some text in your xterm so that it gets copied
2. middle click on the xterm and your copied text (possibly from other window, web browser, whatever) gets pasted at the cursor position
This is really simple and sane behavior but it's completely impossible to achieve with the current version of tmux. I have spend much more time that I am willing to admit seriously trying to do that.
I've run this setup now for something like 5 years across multiple tmux versions and OSes (Ubuntu and Arch) without any hiccups.
But then I think tmux is a tool geared towards keyboard usage and not mouse. The mouse stuff was added because others wanted it, not because it was part of the core idea of what tmux wanted to provide. So if you go against that, you'll bang your head a little.
I did modify the key binds a little bit to make splitting windows and enable the mouse, but otherwise I just don’t need any more advanced behavior.
One change I made was forcing myself to always name a window when it gets created - that way I can usually hotkey back into an environment by its name, rather than having to go searching for windows.
I particularly like that I can use exactly the same toolset on my Mac, Windows, and Linux clients.
I'd like to run a small program that generates a tmux.conf, after asking me some questions, and having me demonstrate my responses.
So step one, it should be able to figure out what version of tmux I'm using. Then it probably needs to know what SSH program I'm using, so it knows how the keyboard and mouse from that program will mess with it.
Picture a Wizard where it asks, "Do you use the mouse to copy and paste? Try to highlight this text: [example1]. Then try to paste it back into this screen." and etc.
Wouldn't this be... kind of an obvious thing to make?
- Iterm2 can now restore sessions, even partially after a reboot (attempts to recreate workspaces). This was the main benefit of tmux for me.
- Iterm2 can also have a visual mode to browse your scrollback buffer, and there are some shortcuts similar to vim. This was the second main benefit of tmux for me.
- It's less keybindings to remember and configure.
- Iterm2 can better size your split panes. You can also change text size per pane. Useful for wide text.
- A bunch of other things that iterm2 does better when tmux is not open. Autocomplete. Paste history. Instant replay. Some of these are quite gimmicky TBH, but could be useful for some.
- Text, colors, etc... appear sharper without tmux. I think. There are antialiasing configs you can mess around with in Iterm2 at least.
- Shell integration. Jump to your last shell prompts in scrollback. Highlight all your prompts in all your panes. Then move to those panes with your mouse without clicking. Amazing.
> Text, colors, etc... appear sharper without tmux.
The renderer is the same, iTerm2 just gets its data stream from tmux rather that from the program running in tmux. There is no difference in the display.
I thought this was just me! Does anyone have a solution for this?
It covers how I use tmux sessions, windows and splits along with Vim buffers / splits / tabs to manage my work flow for developing applications and switching to different projects within seconds.
Despite the video being almost a year old, I work in the exact same way today. It's been a very wonderful experience. My dotfiles are included at the bottom of the post if you wanted to poke around the configs.
The complete system is iterm2 + tmux -CC + et (EternalTerminal) for persistent ssh connections.
Or is Byobu not (or not any longer) tied to any particular Linux distribution (I am an ubuntu user) ?
BTW, for any newbies looking to start out with tiling window managers, I would highly recommend Regolith (which is basically i3 with a nice set of conventions).
This is nice in isolation, but it becomes powerful if you have a persistent target and have a keybinding to issue a send-keys command to the persistent target.
For instance, in my vimrc, I have a set of commands bound like so:
noremap <leader>R :silent !tmux send-keys -t 2.2 startjob Enter <CR>
noremap <leader>E :silent !tmux send-keys -t 2.2 killjob Enter <CR>
where startjob is a local alias to starting my development environment and 2.2 is the target.
This means from any of the vim instances I have, I can start and stop my development environment without having to do so in a running vim instance, and get all the appropriate logging in a terminal that I can switch to when I choose.
This becomes even more powerful with a build script I have triggered by an inotifywait that's running in 2.1 that will build my entire environment with all its dependencies (yes, I need to do it this way because building one project may require another to be rebuilt, and just triggering 'make' in vim doesn't cut it) whenever a file is written.
It reduces a lot of the pain with developing a C++ project in the terminal and lets me get back to the work of just thinking about what needs to be done.
'Send-keys' is, to me, the killer feature of tmux.
I use different tmux colors for different environments so I know where I'm at instantly.
[1]https://medium.com/@victormours/a-better-nerdtree-setup-3d39...
Provides a nice user friendly layer on top of tmux, much recommended.
Fun Fact: Google Cloud Shell is by default Tmux. You can tell, because you don't need to start Tmux up ever if you are in it. Simply hit something like ctrl+b++" and watch your terminal split in two.
It's like a new dimension. Or two, or n, actually.
I'm pretty sure the Buddha once said “Man's suffering comes from not using tmux.” Illusion of impermanence and all that.
Normally, I try to keep to the application's defaults for portability, but the screen key-bindings are in my muscle memory. I was able to migrate to tmux almost seamlessly with just a few key-bindings in .tmux.conf, which is reproduced below in its entirety:
(Edit: formatting)
----
# Remap prefix from 'C-b' to 'C-a' (compat screen(1))
unbind C-b
set-option -g prefix C-a
# Send C-a: 'C-a a'
bind a send-prefix
# Flip to previous window: `C-a C-a' (compat screen(1))
bind C-a last-window
# Make C-n and C-p act like 'n' and 'p' (compat screen(1))
bind C-n next-window
bind C-p previous-window
# Make C-a C-[ act like C-a [ (compat screen(1)
bind C-[ copy-mode
# Change background color of status line from green to yellow for readability
set-option -g status-style bg=yellow
# Increase scrollback to 5000 lines from 2000 default
set-option -g history-limit 5000
----
My tmux bindings are also different, but the logic behind them is the same. Mine are available here - https://github.com/tom-james-watson/dotfiles
I think it's really nice. Well done!
> Mod+V: split vertically
> Mod+B: split horizontally (“bisect”)
That's smart. I love it!
% and " tend to feel... just weird. I can see the visual cue, but it's always been weird to me nonetheless.
Personally I like to try the defaults for a reasonable length of time to see if there is maybe some logic behind why they were chosen. I’ve gotten so used to the defaults now that I don’t think I would change too much except for this one thing:
- Opening a new pane or window was customized to start in the folder where the command was originated from.
Mislav Marohnić has a super nice method of moving between tmux splits and vim splits the same way so you don’t really get stuck thinking one split is actually the other.
This would drive me crazy, but after a little hacking, my tmux/vim combo feels so nice and snappy.
I did have new panes and windows default to the current working directory for a while, and I in fact do this in my own config, but there are security concerns and it was felt it was better that people have to configure it explicitly if they want it.
Personally I use it to organize VT sessions by topic; I’ll make a tmux socket in the root of a project (or at work, ticket) folder and leave things like vim running, that way I never end up loosing vim and opening it twice. You still need a window manager in addition to this to handle efermal windows (browsers, REPLs, other VTs with tmux for other projects etc.)
Also it keeps things from getting SIGHUP. Some fancy VT app probably isn’t going to do that and it’s certainly not going to do it in a platform agnostic way.
# Inherit directory
bind '%' split-window -h -c '#{pane_current_path}'
bind '"' split-window -v -c '#{pane_current_path}'
bind c new-window -c '#{pane_current_path}'
# Vim pane movement
bind h select-pane -L
bind l select-pane -R
bind k select-pane -U
bind j select-pane -D
# Misc
set -g renumber-windows on
set -g escape-time 0
My prefix is Ctrl+F fwiw (on the inner session), I think with capslock as control I wouldn't want to bother remembering and committing to one-stroke bindings.System Preferences > Keyboard > Modifier Keys on Mac, I think it's xkbdmap or such on Linux/X11.
Edit: not to detract from the OP, it looks like they put a lot of thought into the ones they made so I'd do well to give them a shot. I'm happy tmux makes it so easy to bind keys as such.
There are no builtin pane names but if you are running tmux 3.0a or later you can just set a pane user option like `set -p @myname name1` then use it in `pane-border-format` with `#{@myname}`.
https://pragprog.com/book/bhtmux2/tmux-2
It's a quick read and worth the effort. Available through O'Reilly learning online.
Another question to ask is, who would pay for it? A lot of people buy services for things that they can do themselves. But "we'll manage your datacenter" saves a lot more time than "we'll manage your tmux config file", and so is an easier sell. That is why there are an infinite number of cloud providers, or software for being your own cloud provider, relative to tmux config generators.
My point is... there is very little incentive to write such a thing. You won't make any money, and you won't use it yourself. Writing any software takes a long time, so you need some goal at the end. Payment and personal interest both generate a lot of motivation, but "some person I've never met saving a few minutes for free" rarely does. Thus, such a thing does not exist.
My favorite would be a tool that wrote a Linux device tree source file, by digesting the board schematic. Port Linux to your new device with one click! Of course, that would take away a large part of my contracts. I'd have to do some real work for a change.
If the contracts start to dry up, offer it as an automated service. Look at how many people still pay to have someone install and configure things like Wordpress. There's literally thousands of free guides on the internet about how to do it yourself but people will gladly hand over their money to have someone that claims to be an expert do it instead.
https://github.com/romkatv/powerlevel10k#configuration-wizar...
* Work from my desktop
* move to my laptop on the couch
* nick off to a cafe (well perhaps not atm) on an ipad.
* keep tabs on long running processes on my phone and termux.
all with a consistent interface. I think it's worth getting a working knowledge up.
This is what really intrigued me about the article. Most are about remapping the prefix to something easier to type, or using more intuitive mappings, but removing the prefix altogether is different.
I think I might try it for a while. I'm kind of in two minds - on one hand it shortens common actions from a chorded prefix + a chord to a single chord. On the other hand, it makes it easier to clash with existing keybindings and modifiers (readline default bindings use alt/meta and ctrl, my i3 config uses super, other cli apps use ctrl...). It also means I need 2 sets of muscle memory, because I use tmux in many servers and such where I don't have the opportunity to add custom config.
> I guess the funny thing is, this gives a nice bunch of Tmux shortcuts, unless you're using a tiling WM for your system , in which case this is hopeless
Unless you use a different modifier for the tiling wm actions - eg. I use super + <keys> to namespace i3 bindings, which leaves alt/meta free for readline and others.
alias liveTerm='urxvt -bg "#5b0000" -fb white &'
-so my production ssh will be red, staging green, another site purple, etc. -fg white declare -A TMUX_SSH_COLORS_TABLE
TMUX_SSH_COLORS_TABLE=( \
["server"]="fg=yellow bold,bg=black" \
["router"]="fg=red bold,bg=black" \
["desktop"]="fg=white bold,bg=black" \
)
function ssh {
trap 'tmux select-pane -t:. -P "default"' RETURN
for arg; do
local arg_value="${TMUX_SSH_COLORS_TABLE[$arg]}"
[[ -n "${arg_value}" ]] && tmux select-pane -t:. -P "${arg_value}"
break
done
/usr/bin/ssh "$@"
}
On my laptop, `ssh desktop` will switch my tmux colors and then when ssh dies/quits/etc I go back to the default color scheme.> Mod+| for vertical split
> Mod+- for horizontal split
I’ve been using it like that for years, but haven’t seen it in too many places like that. It just feels super logical since the symbols look like the split!
Mod+- might be zoom out though, depending on your underlying terminal app / OS. (e.g. on Linux, I use Meta++ and Meta+- to zoom the whole screen in accessibility mode, and Ctrl with the same keys changes the terminal font size)
I may have to find a way to change one of those because I like your idea very much.
FWIW, I'm always looking for the "perfect" keyboard-only shortcut layout. At one time using AutoHotKey on Windows (long time ago), I juggled with 5 levels of mods and had encoded pretty much all of math, greek, ASCII art and whatnot I could ever use. It was awesome. AHK is the one program I truly, dearly miss on Linux. (at least on KDE, and Gnome afaik, there's just no substitute for the breadth of features and behaviors of AHK).
bind-key | split-window -h
bind-key \ split-window -h
bind-key - split-window -v
bind-key _ split-window -vIt's weird- as I'm typing this comment, I tried issuing "Ctrl-Space %" a couple times just to test, and I get a very slight mental "misstep" because the comment box isn't splitting in half!
Oh, I do this all the time as well! Adding `alias :q=exit` to my zshrc and other tools where I can custom commands just made it beneficial for me instead of a hassle.
tmux -CCPerhaps a solution could be combining a terminal and tmux into one product, so there would be no more excuses, however I don't think core devs are interested in getting a proper mouse support working in tmux.
My point exactly. I want to do that without pressing shift.
As I said in another post, I was a heavy tmux user until I started using Fluxbox. But tmux definitely had advantages. Now in the WFH world it's a good opportunity to try to optimize the workflow again.
Yeah, I mean there's nothing stopping you from throwing up a $5 / month DO server and having your code and dev environment all configured there and then just connect to that from anywhere. As long as your network latency is low it should be quite doable.
Personally I'm ok with keeping things local because I have a single workstation where I do most of my work but I can see how a fully remote set up could be beneficial for some folks.
bind-key \\ split-window -h bind-key '\' split-window -h
is more portable between versions.The worst offense is not even A-Z but rather symbols — take the key "ù" for instance: it's a non-mod key that is used for 1 single word in the entire French language. Literally, ONE WORD in the dictionary. And you need to Shift that 'ù' key to get '%'. How stupid is that...
I won't even comment on the weird 'M' position, which shortens the bottom row (index hits no letter, it's a symbol...) Like WTF, seriously.
Also, top row requires Shift for numbers... (no modifier yields symbols...) What a strange, impractical decision. Every number requires pressing a modifier, but underscore or '&' do not... Sure, yeah, OK.
Should we talk about period '.' requiring a Shift, but not ';' No, no we shouldn't. It's not like a period is common in language...
I thus call it 'weirdest', because it's as far as it gets from ANSI, and it has to be the worst ISO I've ever tried altogether. The question is, why do it so differently? Why not change as little as necessary based on ANSI? Was it a misguided sense of cultural appropriation? Did they like torturing typists and programmers alike?
So one day, as I was learning programming, I decided to stop fighting my keyboard, to preserve my sanity (and limit RSI).
QWERTY US (ANSI) is simply the best for tech (IT, prog). Not necessarily inherently (although it's very good for language), but because of the chicken-and-the-egg: most software is designed by/for US companies and programmers, so symbols like e.g. []{}|/ are used in programming, bash, tools, because they are easy to use on a QWERTY keyboard. And I vastly prefer the 1-row wide Enter to the inverted-L shaped ISO style (less RSI-inducing on the right pinky).
For non-US programmers, there's life before, and after switching to ANSI-US. I'm not even kidding, it's a life-changer in simplicity, comfort (ergonomics) and generally intuition— e.g. there's a reason why ()[]{} are close by. And it lets one buy keyboards anywhere (you'll always find QWERTY, but good luck finding ISO-XX in country YY.
Thank you to anyone who read this. I hope you feel the pain. Now revel in the fact that you weren't born in France and did not have to suffer the computer illiteracy and impractical engineering design of an entire generation before you.
/rant
I don't know if French AZERTY is funny or appalling, I'll let you be the judge of that; I just need to vent 25 years of frustration every now and then, even 10+ years later.
____
[1]: https://upload.wikimedia.org/wikipedia/commons/b/b9/KB_Franc...
So, in short, I hear you brother!
Different kinds of layouts for spanish language is asinine. But hey, this reminds me, Quebec and France also have different layouts. Why keep it simple, when you can complicate everyone's life?
A toast to ANSI and your smart employer!
To work well the schematics would have to be well-formed, there need be a chip database of pinouts, clocks, enables and address strapping, and Linux would need a dts schema (its ad-hoc now). Lots of spadework I guess.
Sure, but this is the internal "copy mode" of tmux, and is not useful to copy text in and out of your terminal.
In most terminal emulators you can also use Shift (or sometimes a different modifier) to bypass application mouse mode and have the terminal emulator handle the mouse event. Of course you can't copy out of the history with this, but that is another limitation of terminal emulators.
This seems more an excuse than a cause. When the "mouse mode" of tmux is off, the copy-paste mechanism works perfectly. There is no reason why this couldn't still be the case when the mouse mode is on. For example, tmux could enable the mouse only for scrolling and resizing the panes, while keeping the correct copy paste behavior intact. But it chooses not to.
Tagline from GitHub:
> Tmux plugin for copying to system clipboard
https://github.com/tmux-plugins/tmux-yank
I could understand if you don't like tmux for other reasons (being a heavy mouse-user for example), that makes perfect sense. It's not for everyone. But if you take some time to understand why some things don't work like you expect it to (like what's the difference between a terminal emulator and tmux, what they have access to and so on) and how you could solve them, you'd avoid the issues you're describing.
But again, tmux is a tool aimed for keyboard users, not mouse. This tool doesn't fit everyone, and that's ok too. If you're willing to try it, you need to understand a few things before it'll work as you expect, otherwise your expectations will be wrong.
I love tmux and I'm primarily a keyboard user. But sometimes I like to copy a short string from one window to another. Does tmux-yank allow you to middle-click paste on a tmux window? does it allow to select to copy?
tmux-yank copies whatever you selected to the system clipboard (xclip, clip.exe, etc.)
For the "select to copy", all the information you need is in the GitHub repository previously linked. Here it is again: https://github.com/tmux-plugins/tmux-yank The specific section you're looking for is here: https://github.com/tmux-plugins/tmux-yank#mouse-support
It's simple for you to try it out as well, have a read about tmux plugins and you'll be up and running in a yiffy.
Also take some time to read up on terminal emulators, shells and what tmux is, as you seem to hold slightly off assumptions around where the problems you're experiencing are actually coming from. The reading and understanding will only make your personal knowledge base larger and deeper :)
To get pasting from the system clipboard, you need something like https://github.com/brennanfee/tmux-paste It will copy whatever's on the system clipboard into tmux's paste buffer, and paste it, all with a single middle-click.
I've only recently started using tmux, and all this clipboard stuff was the biggest stumbling block. But I think I've got things work well enough now.
With xclip, mouse and copy/paste can work over SSH-forwarded X-sessions with C-y and Enter from copy-mode-vi so:
# For older versions of tmux:
#setw -g mode-mouse on
#set -g mouse-resize-pane on
#set -g mouse-select-pane on
#set -g mouse-select-window on
# For newer versions of tmux:
set -g mouse on
bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; #send-keys -M'"
bind -n WheelDownPane select-pane -t= \; send-keys -M
set -g set-clipboard on
# With xclip
bind-key -n C-y run "tmux show-buffer | xclip -selection clipboard -i >/dev/null"
#bind-key -n C-y run-shell "tmux save-buffer - | xclip -i -selection clipboard >/dev/null"
# For tmux 2.4+
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe-and-cancel 'xclip -selection clipboard -i'
For Windows vcxsrv is the simplest and most fool-proof X-Windows server. Anything else on Windows may result in pain.My preference is to reduce visual clutter in tmux by tweaking config and mostly just follow built-in bindings so workflow mostly works on standard tmux as well.
When clipboard fails between environments, sometimes multiple copy-ing, and then pasting into a text-editor helps (not a tmux issue, but clipboard-integrations).
X servers on Windows are often a bigger cut/paste barrier than tmux. As you mention, vcxsrv seems to work better than other choices. Note there are some cut/paste/clipboard options you have to set.
<?xml version="1.0" encoding="UTF-8"?>
<XLaunch WindowMode="MultiWindow" ClientMode="NoClient" LocalClient="False" Display="0" LocalProgram="xcalc" RemoteProgram="xterm" RemotePassword="" PrivateKey="" RemoteHost="" RemoteUser="" XDMCPHost="" XDMCPBroadcast="False" XDMCPIndirect="False" Clipboard="True" ClipboardPrimary="True" ExtraParams="" Wgl="True" DisableAC="False" XDMCPTerminate="False"/> # For tmux 2.6+
set -s set-clipboard externalhttps://github.com/tmux-plugins/tmux-copycat
The other change is to use vi keys for highlight mode:
# set highlight mode keys
setw -g mode-keys vi
bind Escape copy-mode bind-key P command-prompt -p 'save history to filename:' -I '~/tmux.history' 'capture-pane -S -32768 ; save-buffer %1 ; delete-buffer'
then it's all in a file you can work with in an editor of your choiceC-Space marks a region, move arrows to select text, and M-w to copy to clipboard.
q to escape copy mode
This seems to be to the tmux's own clipboard. When you want to copy externally many lines, you can use C-b Z to zoom or use a lame workaround with text files opened in gedit or something. (It's a marginal use case in my experience, so I didn't bother to optimize.)
bind-key -T copy-mode-vi 'v' send -X begin-selection
bind-key -T copy-mode-vi 'y' send -X copy-pipe-and-
cancel 'xclip -in -selection clipboard'
Works just like vim. Press v to go into visual mode, then y to yank the selection#makes clipboard work
set-option -g default-command "reattach-to-user-namespace -l fish"
bind-key -T copy-mode-vi 'v' send -X begin-selection
bind-key -T copy-mode-vi 'y' send -X copy-pipe-and-cancel "reattach-to-user-namespace pbcopy"
bind -Tcopy-mode-vi MouseDragEnd1Pane copy-pipe-and-cancel "if [ \"$(uname)\" = 'Darwin' ]; then pbcopy; else xclip; fi"
to achieve the same thing. It also looks like you can configure copy commands to pipe to a command of your choice with the upcoming version of tmux without having to override keybindings [3].[1]: >= 2.4, maybe?
[2]: Any terminal that supports OSC52 (e.g, iTerm2)
[3]: https://github.com/tmux/tmux/commit/5aba26f2cb7aa9609a3c3d2b...
If formatting is super important, I paste into a file with cat > file, and read the file into Emacs. I can do the same in reverse for a big copy out, and transfer the file.
I do these things because I often use Emacs in a ssh session instead of tramp, because I'm coming from a different OS or need to use modes with sidecar executables, e.g. enh-ruby-mode.
Or you could read it with `xclip`, `xsel` or `pbpaste`, something like:
bind -n MouseDown2Pane run "pbpaste|tmux loadb -" \; pasteb
From tmux 3.2, middle click will paste the top tmux paste buffer by default.