The fact an article like this exists speaks to how bad the keyboard shortcuts for tools like tmux are. It shouldn't be revolutionary to use basic features of a program.
I'm a huge fan of a command window, where you type words to do a fuzzy search of all the commands in a program.
Sublime text and jetbrains products have it down so well to the point of me not needing to memorize key shortcuts. I just have to remember the first few letters and I'm good to go.
I don't think that's fair: this is not news to anyone who has ever used tmux. This post was written for people who have never tried tmux, but who might want to if they knew about this feature. I think tmux actually has good command discoverability (once you install it) -- prefix + question mark lists all the keybindings, with user-friendly descriptions of what they do.
That said, I agree with your larger point completely -- I love Sublime's command palette, and I love using ivy/counsel for M-x in emacs. It would be even better if tmux had something like that.
I've used tmux for 10 years, and for 10 years I've struggled to copy text in tmux. To my defense, the documentation is impenetrable.
That said, so looking forward to copying text in tmux going forward. The instructions in the OP didn't work for me, but I found two other posts - one from 2013, one from 2016, the combination of which worked. Not only can I copy text to a tmux buffer now, but it automatically goes to the system clipboard. This feels like overcoming a major disability.
I'm not sure why everyone goes so crazy over tmux, I've been using screen for 20 years now and it's generally installed everywhere by default, even on remote servers I don't have root on, so I don't have any real reason to switch. 99% of both of these things both do what I need daily, so I usually don't use tmux unless screen doesn't happen to be available for some reason and tmux does. But more power to the devs for wanting to rewrite screen to be more modern with some additional features.
That's always been the argument, but it's always been perfectly fine for me. I'm using it to run long running background tasks, or just let me switch between multiple remote hosts patching / debugging them, not to render some kind of HD game.
And yet... I've been using screen for 20 years and it never seemed inefficient, even when running on a 180MHz Pentium Pro. These days I have to believe whatever it's doing must be pretty minor compared to the overall system performance, but I'd be interested in hearing what it does so inefficiently.
I've been using tmux buffers for quite some time now but what always throws a wrench in my plans is when using tmux in SSH sessions there are always gotchas when getting access to my host's clipboard buffer depending on the platform (windows/mac/nix). The whole reason I dev remotely through SSH is so it doesn't matter what platform I'm coming from.
For example, from Windows these days I'm having to vim yank to file ~/clipboard and then I have a Windows keyboard shortcut to pscp that file locally && notepad file. Hacky, yes, but the muscle memory is there now so meh.
But that's just the flavor of the month this month...
I am by no means a tmux expert but I think I discovered copy paste-yank paste by accident because I use vi keys. Also, tmux on Mac feels weird compared to Linux terminal
I've been using tmux for a while and I didn't know about this.
Just because an app has some features doesn't mean that everyone knows about them. In fact the opposite is true, most features are never discovered and even fewer are used, even "obvious" ones.
Tmux comes from the times when this attitude was okay, but I feel that the standard now is raised and if the UI could give some feedback/help that doesn't require reading through all of the documentation, it's definitely something that should be prioritized.
Anti-example - help screens. Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented while this isn't something that couldn't be avoided.
A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way. The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already.
Tmux is a command line application, and the man page is a well understood convention for anyone operating on the command line. I don't think it's unfair to fault tmux for poor discoverability because its manual is informative, easy to read, and fits in a single man page. It's also unnecessary to "read through all of the documentation" before using tmux, spending 3 minutes to read the first two sections would suffice.
> Press ctr+b, then ?. Compare this to screen's ctrl+a, then ?. Both are quite terrible, but tmux definitely leaves users more disoriented.
There's no difference between the two. People who refuse to read the manual or any of the abundant online tutorials won't be able to deduce either.
> A simple message saying "you are in XYZ mode, type :help xyz-mode to get help" could go a long way.
I'd prefer applications like tmux not stand out more than necessary. Displaying that sort of message every time I press some key can get annoying pretty fast.
tmux has bad UX? ever used this unknown program called `git`?
ultimately a terminal multiplexer (and an editor) are complicated tools with steep learning curves, that's the price of the power that they enable. it's everybody's own choice how deep they want to get into it and how much time it saves for them.
do you have trouble finding tutorials for tmux? youtube is full of them.
and there can be so many because the docs are excellent...
> The RTFM philosophy combined with a wall of single-file manpage with no tutorial is something that I really wish died already.
With respect: what do you do for the tools you use to help this situation? The software is open source and accepts patches, and I'm sure they'd love to accept a patch that adds user-friendly documentation to the tool.
It sounds like a loaded question, but a perfectly valid one :) If you're asking whether I actually change the tools I complain about then the answer is "no".
The reason is that if you hate how, say, coreutils works and have a strong vision of how it should be restructured, it will boil down to being off-putting to the mainteiners at best and - at worst - becoming a rewrite anyway. This is why I see my role as more of a propagator of tools that want to dethrone the current defaults: I look out for new exciting projects that have wildly better ergonomics than what's most common and I recommend them to my friends. And given that I'm running a hackerspace in my city, I have a bit of a reach so I think that this strategy might be a net good. I also try to share knowledge on how to code and keep in touch with FLOSS communities, so while I might not be contributing code directly, I (hopefully) end up bringing contributors anyway.
And while we're talking about spreading the word when a project has good ergonomics, here are some examples I personally love:
1. "glances" - a tool that combines a couple of tools like top, iftop, iotop and various other monitoring programs into one CLI dashboard. It's a bit chunky, but its functionality justifies it.
2. "fd" (cargo install fd-find) - a simpler version of "find". instead of crazy "find -iname 'something" you can just do "fd something". It's also faster.
3. "ripgrep" - like fd, but for grep. Defaults to recursive grep and skips .gitignore, so you can just type "rg variableName" and see all occurrences of it within files in your directory tree.
But you're right, I love to complain and quite frankly, in many cases I'm disappointed by priorities some projects choose in terms of ergonomics. Disappointed up to the point that I gave up sending patches - or even filing issues (example: GitLab). Perhaps a solution to the problem would be to have something like a GitHub badge signalling "UX feedback is welcome" or "RTFM", depending on one's design philosophy? That would help developers reach their target audience, regardless of which side of the argument they prefer.
Been using it for about five, and honestly I stopped using this in my workflows a long time ago. My workflow now is to ctrl-a+z to maximize the pane, highlight (with the mouse) and hit ctrl-insert to copy and ctrl-shift-insert to paste, then ctrl-a+z to restore the pane. It's still a bit of a pane, but it's deeply ingrained enough into my muscle memory that it's smooth.
But... sublime is my text editor for notes and SQL. Everything else text related is in a terminal with vim mode enabled universally. Not sure why SQL is so annoying with vim..
If you `set-option mouse on`, tmux will let you use copy-mode just by clicking and dragging (intelligently within panes, negating the need to resize-pane -Z). But TBH I often do almost the same thing (but Xorg does its part of the copy-pasta without forcing any Emacs-esque three-finger keyboard chording, thank goodness), selecting text is the only thing I ever use the mouse for in the terminal (except rare scrolling, especially overflowed weechat bars), so I keep tmux’s mouse support off.
Ah yeah, I use that configuration option (love it), but I think the issue is that highlighting text doesn't stay highlighted unless I hold shift -- which shifts the mouse functionality to the terminal emulator. Maybe there's a setting to get around that, but it hasn't been a big enough deal to really try and figure out.
One feature to improve the discoverability of sequences of keypresses/chords is a which-key style UI. e.g. a panel will show the available set of next inputs which can be handled, and what their command is. https://github.com/justbur/emacs-which-key#more-examples
I agree with the command discoverability. Not only does prefix+? show you the commands, it is also searchable, and if you use vi-mode, it uses the same search commands.
> Sublime text and jetbrains products have it down so well to the point of me not needing to memorize key shortcuts.
Right, but you dont run things _inside_ sublime text. Keep in mind tmux has to play well with hundreds of existing shortcuts that people expect to work.
When you are attached to a tmux, you don't want to override the shortcuts of something you may run inside the tmux.
All the terminal shortcuts are expected to work (Ctrl-E, Ctrl-Arrow, Ctrl-A, Ctrl-E, Ctrl-E, Ctrl-Q, etc..).
All main program shortcuts are expected to work (vim, emacs, etc)
And of course not desirable to override screen shortcuts.
I never used GNU screen as its command prefix, ctrl-k, conflicted w/ the command prefix for my preferred editor, JOE, and I was always too lazy to reconfigure the bindings. tmux uses ctrl-b by default, which smoothed the way to using tmux. I'm still too lazy to learn any tmux commands; the only one I know off-hand is ctrl-b-d, for detaching, which is sufficient for my needs. Scrolling is annoying in tmux sessions because I don't remember the commands, but I compensate by avoiding tmux when I might need the scroll buffer or by tee'ing output to temporary files.
I'm suprised anybody uses JOE as their preferred editor. I have never met anybody even mentioning it, but obviously people have different backgrounds.
I've used Unix in the 1980s the first time and learned that whatever your preferred editor is, you need to know vi, because vi is always installed. That has been true in my experience with a single exception. In a recent embedded Linux I used they had only nano available.
So what is the story behind JOE and what is good about it?
I used JOE for a long time back in the day and I remember it fondly for plastering its documentation right onto the screen so you didn't have to look stuff up, as a beginner. This sounds embarrassing but I suspect others have had the same problem so here goes:
Back in the day (in the 90s) I was just starting out with linux, and had to install slackware from floppies I carried to school and to the library, a handful of packages at a time. I didn't have documentation packages installed yet, but I did have some howtos. So I had to edit some files, and I tried the "standard" editors - vi and emacs. I didn't know how to quit vi or emacs. I'd end up trapped in them, and eventually figured out I could Ctrl-Z and kill the process for vi. This didn't work on emacs so I'd end up switching to a second virtual terminal and then kill the emacs process. I had no idea what I was doing, and being unable to get out of a program and get back into a safe known state was quite traumatic to teenage me just getting into unixy stuff. JOE was there for me. It did what I needed it to do, it told me how to operate it, and I never once got stuck in it. Out of gratitude, I used it exclusively for years. It's zero bullshit, it edits files, it doesn't let you down.
wordstar. If you are used to wordstar, joe is a blessing.
There are a few greybeards and I mean that literally who swear on WordStar, GRRM most famous of them but Robert J. Sawyer does too. So it's not unreasonable to think there are other, less famous people who still use it? and want to use an editor with the familiar keybindings.
Not me. I am completely up to date with software and my favorite word processor is WordPerfect 5.1.
Also, Turbo Pascal 3.x's editor took Wordstar shortcuts. Only years later high school me only learnt that those strange ctrl-k commands were archeological artifacts...
I am ashamed but I forgot the Turbo Pascal hotkeys :( it's been ... a long , long time since I opened TURBO.COM. Some of these do fall out of memory. I once knew the full 300+ opcode list for the Z80 so I could read machine code and disassemble it in my head, now I only remember C9 being RET :( I blame high school, it was too intensive and it crowded this out of my head.
I launched it a couple of years ago to show my kids what I did as a kid. I had forgotten pretty much every bit of Pascal (and I actually wrote Object Pascal at the end of the 90s!) But all that writeln stuff has left my brain.
I use JOE in its "emacs-ish keybindings" mode (which you get if you run it as 'jmacs') for small "just run an editor in a terminal to edit this config file" jobs. I wanted an editor which was fast to start up, terminal-based, and emacs-like, and this was the one I found 20 years ago. It's always been reliable and it's always been available as a Debian package, so I've never felt a need to look for something else.
For long running edit sessions I use real emacs; I know you can set that up in a client-server arrangement to avoid the startup speed problem, but I never had the effort to investigate that; besides, sometimes you want to edit a file as root, who won't have a long-running emacs.
For editing a file as root in emacs, you can use TRAMP to connect to your same machine as the root user. I think you also have to toggle a read-only mode afterward.
Piping output to a file is much more preferable in my opinion, but you can access scrollback with ctrl-b [, then j/k for up down and ctrl-u/ctrl-d for jumping up/down.
The general problem with these kinds of TUI apps isn't the shortcuts but the complete lack of discoverability of the commands and their shortcuts. The expectation that people have to go and the read the documentation and then memorise the shortcuts is ridiculous.
GUIs for decades have demonstrated practical ways of making commands discoverable and also teaching users the keyboard shortcuts. All without having to ask people to RTFM. It is a pity that so many TUI apps haven't learnt the same lessons.
There is a reason why Nano became such a popular default editor for email. The shortcuts are printed at the bottom of the screen(!)
I hope more TUI apps pick up on the idea of the command palette though. It is a fast and keyboard friendly way of improving usability.
Good GUIs can be discoverable yes, but what about about Windows XP's file explorer shift right-click option (to make reappear 'Open with..'), Windows 10 right click on the 'start' menu?
Do you find these things discoverable?
The truth is that being pretty/fashionable matter more than discoverability..
It's not about being flashy. Those Windows commands are hidden precisely because they are for power users and Microsoft presumably thinks that average users don't want or need them. Which is a whole different can of worms.
If tmux or screen had two rows worth of UX like nano does... it’d use them way more. I see the value of those programs but they are so not core to my workflow that I can never bother to remember the keyboard shortcuts.
Ubuntu has some wrapper for tmux called byobu that does exactly this. It is the only time I really enjoy using this sort of tool.
I see it as a kind of trade-off. Good GUI apps do make it much easier for commands to be discoverable to new users of that application. What they sacrifice is generally smooth and rapid keyboard control and more sophisticated composable commands. To make use of that, you pretty much have to be a power user and spend a lot of time drilling keyboard commands and how they can chain together into your head. Once you do that though, you can do a ton of advanced things really fast while hardly even thinking about it.
> The fact an article like this exists speaks to how bad the keyboard shortcuts for tools like tmux are
Well, tmux is not an editor but a terminal multiplexer — its keyboard shortcuts are like this as to make sure they don’t interfere with any editor’s shortcuts running in the terminal.
I learned of byobu several years ago from a coworker. I think of it as (but may be technically incorrect) a wrapper on top of tmux (or optionally screen; behaves the same-ish either way?)
Cringe. The copy and paste buffer is inspired by vi btw. Do you have a problem with vi in addition to tmux?
That is to say, it's dead simple once it's explained to you. The issue is with documentation, not the keyboard shortcuts themselves.
Sublime Text and Jetbrains are also vi-inspired. For where Jetbrains doesn't go far enough there is a vim mode plugin. I would say these are strong indicators of vi's dominance among keyboard shortcut layouts.
I read the documentation; and the shortcut is explained in the documentation. I've been using it for years already. I think that maybe the problem is partly that people just do not bother to read the documentation, and expect the tool to take them by their hand. Do we expect that from the tools we use? Is that good software?
I use Vim every day and love it. And I found tmux' configuration style and controls so confusing that I gave it up completely.
You want Vim-like controls? Use dvtm. It lets you open the content of any terminal in Vim, and from that point you can do anything from selecting/copying text up to saving a snippet in a file with a simple ":w foo".
All that aside, clipboard copy-pasting in Vim is absolutely horrible out of the box.
> Jetbrains are also vi-inspired
Not sure about that. The tab management and window splitting alone feel near unusable to me, because like many other modern apps they are convinced I only want to switch tabs in a seemingly random order(instead of, you know, the order that's literally shown on screen), and none actually have Vim's tabbing where a tab can contain multiple buffers, not the other way around. And guess what, no Vim plugin I know ever touched tabs. Probably because people not using Vim think the UX is all just in some arcane keybindings.
I use Vim for basically everything too. I do find it a bit irritating that most GUI editors do tabs within splits, instead of splits within tabs as Vim does it. I guess the behavior of tabs within splits is baked into most GUI APIs and frameworks so deeply that it would be virtually impossible to change at this point though. Oh well.
I'm more irritated though that Vim has nice keybindings for any sort of changes you might want to make to your tab and split setup. I don't think any of the GUI tools support keyboard commands for any of that. Or at least if they do, I haven't been able to figure out what they are, and am probably honestly too lazy to try to develop muscle memory for how they work.
> I guess the behavior of tabs within splits is baked into most GUI APIs and frameworks
Yes, that is probably a common assumption. On the other hand it may not be that hard to just do the tab bar and split containers separately and handwire them together via input events. At least web UIs aren't exactly famous for their adherence to any standard.
So the more likely reason is that most developers just don't have a reason to do it. Because in the end Vim's approach is just more an exception and as far as I know Vim tabs weren't even originally intended for the same purpose - and I can confirm buffer switching within a tab can be pleasingly fast and precise thanks to the tab completion.
> because like many other modern apps they are convinced I only want to switch tabs in a seemingly random order(instead of, you know, the order that's literally shown on screen),
If you mean the behavior of Ctrl-Tab, yes, that's confusing for me too. But you can switch using the order shown on screen though, by using Alt-Left / Alt-Right.
> But you can switch using the order shown on screen though, by using Alt-Left / Alt-Right.
Can I also press a button to swap those keybindings back to the old behaviour so I don't have to work against my own muscle memory?
Or better, can I tell it to switch tabs on Spacebar-l and Spacebar-h like I have it setup in Vim? I often wonder if it's too demanding to expect keybinding flexibility that was available decades ago. I get that it's a niche use, but then again it's marketed towards professionals and power users.
Last I checked, tmux binds are all emacs-like until you change your config. I remember the copying stuff suddenly being easy once I toggled the vi-like keys. Maybe you haven't used an unconfigured tmux in a while.
tmux actually tries to be clever here and guess if you're a vim user or not: if your $EDITOR contains the string "vi", you get vi-style keybindings by default. If it doesn't, you get emacs.
But unfortunately it doesn't look at $VISUAL, so... yeah, you usually have to set it explicitly.
I first encountered the fuzzy search command bar shortly after I started using Mac OS X 20 years ago when I discovered LaunchBar. This revolutionized my computer usage. Basically bringing the power of CLI to GUI
It took quite a few years fir this to be picked up by SublimeText, but wow that was another huge boost. No longer needing to learn tons of keyboard commands to navigate an application.
I wish an OS would deeply bake this idea in. Apple has done good job with Spotlight for the system level (I still use LaunchBar on my own systems) , but I want this functionality to be shared between System and Apps
The large numbers of keyboard shortcuts is a feature - like learning a piano piece or something, once you have muscle memory you can fly thru the commands. Having to look at anything other than the output of your command, like a suggested completion is slower.
Lets just say I am very keyboard centric. I have used computers for nearly 40 years. I automate the my systems with extensive Keyboard Maestro and AHK scripts, use multiple layers on my programmable hardware keyboard, LaunchBar or Keypirinha. When editing text I seldom touch the mouse or use the menus. I have mostly made Windows 10 bend to my highly MacOS inspired keyboard focus
On Linux, I mostly restrict myself to the CLI. When I try Linux GUIs, I am frustrated with the lack of keyboard consistency in the GUI, but I have also never given it the months of time it would take to bend the Linux GUI to my way. (I do customize the heck out of the CLI)
This is what Ubuntu tried to achieve with Unity. Even as far as being able to search for GUI commands within individual applications. I thought it worked pretty well and was gutted when they scraped it.
Yes thanks for mentioning that Apple’s cmd-/ I fell it gets us about a third of the way to a command bar. I prefer this to Windows alt key navigation of menus.
Tmux is a great replacement for screen, but it's true that keyboard shortcuts are atrocious, I think every shortcuts that I use daily are remapped in my tmux.conf. Also when I copy in tmux it automatically change the clipboard and vice-versa, very useful to copy errors or paste snipped of code from internet. And with 'mode-keys vi' it's even faster.
Same, I thought I'd be cool and learn tmux (after 25 years of Linux/Unix use). After a year I realized it's just easier to learn the keyboard shortcuts of my favorite terminal client and tile the windows.
I've been messing with Emacs lately, tab completion in M-x is amazing. The editor is surprisingly discoverable because of its "minibuffer" command window.
Using the tmux vi keybindings to copy and paste between panes is great if you haven't tried it.
This copy/paste workflow is really nice for working with kubernetes on the command line.
E.g., imagine that you need to delete a kubernetes pod.
You'd run a few commands like this:
1. `kubectl get pods`
2. Find the pod id, and copy it using mouse & some shortcut
3. `kubectl delete pod <pasted-pod-id>`
Instead of this mouse workflow, you could do something like this in tmux:
1. `kubectl get pods`
2. Find pod id, `Ctrl+b [` to enter tmux's vi selection mode
3. Navigate to the section you'd like to copy; e.g. `k6ww` (up six lines and over two words, for example)
4. Press space bar to start selection, and use common vim movements to highlight what you'd like to copy (e.g. w or $)
5. Press return/enter to copy the selection
6. This text can be pasted with either Cmd/Ctrl+v (it gets copied to the system clipboard for me on macOS 11.2.1 with tmux 3.1c_1 from brew), or using the default tmux shortcut `Ctrl+b ]`. So that would allow you to type `kubectl delete pod Ctrl+b ]`.
So yeah, it's a few more steps, but it's a lot faster for me.
These are the relevant sections of my ~/.tmux.conf file:
# Use vim keybindings in copy mode
setw -g mode-keys vi
# Use emacs keybindings in the status bar
set -g status-keys emacs
(I mention the `set -g status-keys emacs` config line just as an FYI since it's been really helpful for me with tmux. I've never liked using readline-type inputs with vi-mode.)
Have you tried k9s [1]?
Just being able to run common operations directly on k8s entities is so much better than having to run a separate command.
It also uses vi-style hotkeys.
That's a fair point! The kubernetes example I gave is somewhat contrived, but I will say that I prefer to have whatever resource id I'm working with in my clipboard vs. relying on myself to select the correct one in a tab completion menu.
Where I really like this tmux copy/paste workflow is for grabbing multiple lines of command output. From there I can paste that into some message on slack, or use it as the body of a PR message that describes some error or shows some output.
For the latter case, I have a zsh function that calls `hub` to open a PR, drops me off into vim, and once I `:wq`, it will send the API request to open the PR, and then open my browser up to it. This is the command I have in the function: `hub pull-request --push --file "$filename" --browse --draft`.
Can you give me the bare minimum tmux config that does what you are saying? ALl these tutorials in this thread don't do anything (i just installed tmux and I'm using iTerm 3 and oh-my-zsh on OSX). I'm assuming because my tmux config is empty (I also dont want to disable other features like the original link because I use tmux for actually attaching to sessions)
AFAIK, you'll need to have at least `setw -g mode-keys vi` in your ~/.tmux.conf file to allow tmux to use vi keybindings in copy mode (`Ctrl+b ]`). Make sure to fully exit all tmux sessions and start a new session after making that change.
I have basically the same setup as you, and I think that's the only thing I've manually configured. I also run the oh-my-zsh tmux plugin, and iTerm2's tmux integration, which seemed to work out of the box for me.
I type `Ctrl+b [` and in top right it says [0/1] (even if i have a history of say 5 commands). when i press any vim knpfb keys the cursor doesn't do anything. I feel retarded
The parent describes how to do this with tmux right out of the box -- you don't need anything in your config to get this to work. Did you start tmux? If you haven't set up iTerm to connect to a tmux session by default, any new tabs/splits you make won't be running it. You should be able to tell by the presence of the status bar at the bottom.
I type `Ctrl+b [` and in top right it says [0/1] (even if i have a history of say 5 commands). when i press any vim knpfb keys the cursor doesn't do anything. I feel retarded
This sounds terribly convoluted compared to turning on mouse mode and selecting the text with your mouse. It should copy immediately after you release the button, and you should be able to paste with your standard shortcut if you set up tmux to use the clipboard of your choice.
Mouse-driven flows are always a little more intuitive and discoverable, but keyboard shortcuts are more precise and can be lightning fast once you have muscle memory.
Listed the way the parent does it seems very complicated, but if you have the sequence memorized and trained it can be executed very quickly and without moving your hands from the keyboard.
Ah! Thanks for pointing that out. That's the piece I forgot about here. iTerm is populating the system clipboard from tmux because of the tmux integration [1].
To me, copy/paste is a weakness of a workflow using tmux.
With tmux you end up with four distinct copy/paste buffers: the OS, tmux, the shell, vi/emacs. You do get used to the mental gymnastic of juggling all those but it's not ideal.
Same goes with managing the windows of the OS, tmux and vi/emacs.
Works great till you want to copy a ton of text. I frequently need to look up some command to dump the tmux scrollback to a local file because I could only get a couple thousand lines from the buffer.
It's the best option I've found, but it's not all smooth sailing for me at least.
Same on macOS with iTerm's Tmux integration, everything just uses the system clipboard buffer seamlessly, even when copying inside tmux on a remote ssh connection.
Oh, yeah. I can't keep multiple clipboards straight. I configure everything to share the OS clipboard (except my shell... but I don't really use my shell's copy buffer since I got in the habit of using ctrl-q).
tmux will copy to your system clipboard by default if your terminal emulator supports the right escape sequences. If it doesn't, then you do need to configure it to shell out to xclip or pbcopy or whatever. It's annoying, but I find it less annoying to configure it than to try to keep multiple copy buffers straight.
I use the vi mode for tmux and my shell (zsh).
I configured tmux and neovim to copy into the system clipboard (not for the shell, I did not search to be honest)
Thus to copy I use the y (yield) key, with optional selection keys like iw (in word), t<char> (to <char> included), f<char>( to <char> not included), etc.
But my mouse selection copy works differently between vim and tmux. In vim, when I select text with the mouse I have to press y to copy it. In tmux it is copied without pressing any key. So there is improvement here because often the paste fails after selecting text in vim because I forgot to press the y key.
tmux is what made drop tiling window managers after I realized I was only using tiling in a terminal. (I use Gnome on Linux.)
It's three. The shell doesn't do copy-paste, unless you mean the terminal emulator, but then that's copy-paste as in "the OS". This is actually great because you get many more cut buffers this way. There used to be a utility called xcb(1) to manage X11 cut-buffers (yes, there's more than one!), but even so, that requires too much mouse use. With tmux and vi/vim/emacs you get many cut-buffers. If, like me, you run a $EDITOR per-pane, then the tmux cut buffers are most useful when cutting and pasting between panes, while $EDITOR cut buffers are most useful when cutting and pasting within a file.
You can copy and paste in bash and zsh with emacs keybindings (by default). I will sometimes start typing git commit -m "something...", then hit ctrl-a ctrl-k, then stage another file, and then later ctrl-y to finish the commit. But ctrl-q basically does that same thing, in a nicer way. I don't know how to get bash/zsh to integrate with the system clipboard.
I think a more killer feature of tmux is that you can send keystrokes to apps running inside tmux (with send-keys). It just opens a door for scripting CLI apps that otherwise would not be scriptable. e.g. irc clients and similar full screen apps.
Yep. This is a killer feature for me. I have a ton of scripts that open new split screens and ssh into things to tail logs or others that ssh, change users, start some other console/repl/shell, then run a few commands in that. I'm sure there's better ways to do it but it's been enough to speed up a lot of the simple repetitive things for me.
To add to this, I have used tmux for automated testing of full-screen interactive command-line apps. It comes out like PhantomJS: send-keys + capture-pane is pretty awesome (once you overcome dumb timing stuff).
At my first SWE job I pair programmed every week with a greybeard who used vim and tmux (and didn't own a cellphone). I continue to be grateful for his mentorship
I tried playing with it but it doesn't seem to recognize my control key (???) which makes a lot of things... hard. A quick google and glance through the settings didn't reveal any likely culprits, but I expect it's some macOS thing. Anyone know what's up with that?
Yeah, I couldn't figure it out looking through the default alacritty.yml. I'm not trying to use the normal system shortuts, but like, ctrl-d to EOF and ctrl-c to SIGINT and that sort of thing.
I've been using neovim as my terminal multiplexer for a couple years now. I can use all the same key commands for yanking and pasting buffers from a file buffer to a terminal buffer.
I will say that at default it's kind of a pain switching between terminal buffers and normal buffers. <C-\><C-n><C-w>l is just too much to type over and over. I do <Leader>l as the way of escaping any buffer I am and and moving the buffer to the right
For me, when I went and tried a vim terminal buffer a few years back, I learned that my habituation to the emacs-style shell shortcuts (ctrl-a, ctrl-e, etc) was a significant (and dumb) barrier, that I didn't care to overcome.
I haven't used neovim, but it certainly is possible to use vim with its terminal feature as a terminal multiplexer. The way I do it is to use a single instance of vim to handle the multiplexing and just run whatever I need in different split windows or tabs.
If I need to copy, I'll use the terminal normal mode (ctrl-w N) and visually highlight text and copy it to the + register. Then I can paste the contents in another application. The only issue I've encountered is that some text that's not supposed to be wrapped has line breaks added at the screen width. In that case, I'll paste the text into another vim buffer first and remove the line breaks using gJ. then copy and paste it into another application.
For copying text from another application back into vim, I'll just highlight it with the mouse and paste it into vim using ctrl-w "*
For me, the killer feature of tmux is actually the mouse support (e.g. clickable window names, pane selection, scrolling, copy/paste), which works even over ssh.
Yes, but it's a shame that tmux is not a good "x11 citizen". If you select some text inside tmux, you cannot middle-click on another window to copy it. Likewise, if you select some text on a non-tmux window, you can copy it everywhere, except on your tmux session. For me this means that the mouse support is severely broken, and I actually prefer to use "tmux set mouse off", by which all goodies are lost, but at least I can copy-paste like a human being.
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:
wow, 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?
Yep! 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.
Yes, that's what I've been doing for years, and I hate it (to the point of disabling mouse support). It is extremely annoying to have to press SHIFT for normal operations that work out of the box in every other program.
Fortunately, thanks to ianthehenry's solution on this thread, you can do the same thing without pressing shift!
I'm probably an outsider here, but as an iTerm user my usual way to copy short pieces of text from tmux is to just disable mouse reporting, select the text with my mouse, and do the good old cmd-c. Not really a sophisticated approach but it gets the work done, and works just as fine on remote tmux sessions.
If you weren't already aware, you can just drag the selected text slightly and it will retype it at the current prompt position, without dirtying your clipboard. QTerminal does the same on Linux, and likely other terminal emulators, too
Or if you are copying it out of iTerm, replace "slightly" with "to the other terminal" :-)
If your terminal emulator supports the clipboard escape codes, then yes -- it just works, and there's nothing for you to do to set it up. This is because when you hit "copy" tmux just prints a bunch of escape codes, and ssh will re-print the escape codes locally, and your terminal emulator will see them, and know to set the contents of the system clipboard.
If your terminal emulator doesn't support the clipboard escape codes, then you have to configure an explicit copy-pipe command, like this:
And that will work on a remote tmux, as long as you ssh to the remote server with X forwarding (ssh -X or -Y).
If you're not using X and your terminal emulator doesn't support the escape codes, then I think the answer is no. Like if you're using a Mac and using Terminal.app instead of iTerm, I'm not sure how you would make this work.
This should work the same locally & on remote hosts. Tmux doesn't care that you're ssh'd into some host.
As long as your system & version of tmux supports copying to the local clipboard, you should have no problems pasting with either Ctrl/Cmd+v or `Ctrl+b ]`.
Otherwise, if the clipboard is broken for some reason, you can stick to using `Ctrl+b ]` to paste.
I use iTerm 2, I like its copy mode[0]. Feels quite natural with mac's keys. Check these simple instructions [1]
1. Enter copy mode with cmd+shift+c.
2. Basic Vim keybinding, many keystrokes can active different actions.
- v to select by character.
- shift+v to select by line.
- ctrl+v for rectangular selection.
- ctrl+space to stop selecting.
- y to yank/copy the selection (also exits copy mode).
- q to exit copy mode.
I use tmux (inside mintty) on my windows work laptop to pretend I am on Linux. Have been using this copy paste feature regularly too. Didn't realize it was so niche. Tmux is easily the most indispensable piece of software for my workflow. How else would I jump across different work spaces at lightning speed?
For people unfamiliar with tmux these are some other features I use -
C+a . space -> switches layout from vertical to horizontal and back
C+a . , -> lets me rename the window so I know what I have open there
C+a . [ . C+s -> search in previous output. n lets me me then jump to next occurrence of what I am searching.
One thing I've tried recently is running the terminal command inside vim. You have vims features of tabs and windows, plus being able to copy and paste between the terminal and editors all within vim. I'm still undecided if this is a good workflow or not.
I wish tmux had the ability to pipe the buffer to some external program, e.g. vim. Their vi-mode is okay, but it's never going to be the same as native vim with my configs, plugins, etc.
That aside, I do really enjoy tmux and appreciate the hard work of the devs!
Or bind that to a key. -p is "print to stdout", -S specifies where to start and - means "the beginning of history" (by default capture-pane just gives you the visible contents). I'm not sure how to do the same thing with the current selection -- copy-pipe doesn't seem to work with vim, for some reason.
And with that I can just hit `<prefix> u` to pipe the current pane into urlview. Typical use is for example when pushing to a branch and bitbucket prints the URL to create a PR to stdout. I hit `<prefix> u`, `<enter>` and the link is open in Firefox.
Thanks, that seems close to what I'm looking for, but I'm not sure how to get a keybind that has behavior similar to scrollback mode. I think tmux is missing the ability to give control over to an arbitrary shell command. For example, if I bind that to a key, I can only run it in the background right?
I switched from using tmux to using only Vim a year ago and I'm not looking back.
I'm opening an instance of Vim per projet and that's it. I use the :term command for running any CLI tools that I haven't integrated to Vim yet and I can use normal and visual modes on their output.
I'd recommand using tmux over your terminal's splits/tabs but I'd definitely recommand dropping tmux if you are nesting something smarter in it (emacs, vim).
However, this only works fine within tmux alone. When you select text in tmux, you can’t use middle button to paste them into other programs, the opposite is the same. I don’t know why.
Then you can paste your tmux selections into other programs with middle-click -- I think by default tmux only uses the "clipboard" selection, but middle click pastes the "primary" selection.
Wow thank you, this binding works very well! It used to be very annoying to copy-paste between tmux and other softwares, but there won’t be any problems in the future!
Not Tmux, but one of my favourite things about iTerm2 is the search/copy functionality from the keyboard. I often find myself reaching for it, for example
git log - see a commitish I want to fixup
cmd-f type first few letters
hit tab to get to the end of the commitish
cmd-c
esc
cmd-v to paste it
The other great thing is when you have cmd-f going and there are multiple hits in your terminal, hitting enter cycles you through them backwards.
The advantage of this is that you don't hijack M-v from a real emacs running in tmux. It's only active when I need it to: while sitting at the shell prompt.
I guess you could also bind it to PgUp or C-u if you are using the wrong editor.
Two things I've struggled to get working on my tmux is with mouse selection. While I use the keyboard way more, sometimes a mouse is easier.
Anyway, when I select something with a mouse, it is not possible (or at least I've not found a solution) to let go of the MB1, and that automatically quits visual mode. And the other thing is when you scroll down to the bottom, it automatically quits visual mode.
You can have your mouse copy and get you out of copy mode like this:
# native mode, if your terminal supports it
bind-key -T copy-mode-vi MouseDragEnd1Pane send -X copy-selection-and-cancel
# or if you're using X, and want it to work like any other program
bind-key -T copy-mode-vi MouseDragEnd1Pane send -X copy-pipe-and-cancel 'xclip -i -selection primary'
Vim's :term command has become my go-to way to open up a terminal nowadays. It gives you nice terminal emulation, but also lets you stay in Vim and use all the Vim keyboard mappings. When a terminal window has focus, you can go into Normal mode with `Ctrl+W N`, which will let you search and yank stuff like you're used to.
Even more awesome: vim-repl (https://github.com/sillybun/vim-repl) uses the :term feature to provide convenient communication with any REPL, with extra support for some languages such as Python.
(In fact there are a host of these; for example, vim-slime now can communicate with Vim’s built-in terminal.)
Been using Tmux for around 6 months. I frequently use prefix + [ shortcut but always thought of it as "Scroll mode", never realized that its called "Copy mode" nor that one could copy text using keyboard.
I've used Tmux for around 8 years, and I've never had a pleasant copy/paste experience. This is not for lack of reading plenty of Google search results, installing different plugins, aliasing long command strings, to keyboard shortcuts. In the end, I'm still back where I started. I grab my mouse, highlight the text and pray that it's not longer than what fits on the page. I then hit Control+Shift+c, and I have the text on my clipboard. I've heard that there is a way to do this in a more vim-like fashion, but I've never actually gotten it to work. I used "Copy mode" every single day to be able to read what's in my scrollback buffer (test results, error output, etc) but using a key to start highlighting and copying contents to my clipboard? Man, that'd be awesome.
I am curious to hear about your experience. What OS and terminal emulator do you use? Do you run tmux on a remote host that you SSH into?
If your terminal emulator doesn't support copy escape codes, and you're running it on a remote server, you need to ssh with X forwarding in order to share your system clipboard.
I realized over the course of this thread that I know a weird amount about configuring tmux. I rely on this feature pretty heavily, so I've had to set up system clipboard integration on Mac and Linux across on multiple different terminal emulators. I'd be happy to help you get a config that works on your system, if you want.
I'll definitely give it a shot. Although I didn't reply to this thread expecting "tech-support", it certainly is appreciated when fellow tech folks are willing to share what they've learned. So, thank you.
But you can configure it. And it is quite usable even without it. The copy-buffer exist for all tmux session on the same system (tmux-server) so you can share between different panes/windows in current session as well as other sessions.
Exactly. Granted, I've spent some time on my tmux config, but it is just how I want it, and it's incredibly productive. I can copy to/from the clipboard/selection just fine, between windows and vim and firefox, etc. using the keyboard or mouse. I can go into copy-mode-vi (scrollback buffer) with the PageUp key or mouse wheel from the shell (not from within apps). And the added bonuses of, for example, popping a tmux window of fzf git branch output to choose from for a checkout is nice.
I'm a huge fan of a command window, where you type words to do a fuzzy search of all the commands in a program.
Sublime text and jetbrains products have it down so well to the point of me not needing to memorize key shortcuts. I just have to remember the first few letters and I'm good to go.