Spent too much time wonking a tmux config only realizing it was never going to work how I liked. You can't have it all with the mouse no matter your settings, there will always be a compromise. It also doesn't help that no one cites the version of tmux they wrote their configs for, nor that the configs are not backwards compatible with all versions of tmux for all settings.
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.
> realizing it was never going to work how I liked.
> 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.
Make your own cheatsheet for bindings you need. This way you learn faster and optimize for your own needs. Tmux is exceptional mouseless, though personally I prefer combining with mouse.
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).
"For Windows vcxsrv is the simplest and most fool-proof X-Windows server. Anything else on Windows may result in pain."
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.
I'm used to selecting only with Space, and confirming with Enter. C-b ] pastes.
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.)
I haven't got my config to hand, but essentially I've binded leader-y and leader-p to copy and paste respectively both using the system clipboard. Since doing that tmux has been so much more useful to me.
This is the section of my config that sets up using the clipboard for tmux buffers. It won't work as is unless you're using both fish shell and Mac, but this should at least give you some good keywords to google and find documentation on how to do it for your system
You can achieve copy-pasting that isn't very different from a typical GUI without deviating too much from the defaults. If you use a sufficiently new version of tmux [1] and a terminal that supports it [2], you can just right click and drag your mouse to select and copy text into the clipboard. All you need to do is put the line 'set mouse on' in your configuration. If your terminal doesn't support this feature, you can do something like
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)
I use Emacs copy & paste, or readline. I don't do a lot of copy & paste between different windows though. Paste in works adequately (terminal stuffs it into keyboard buffer) but may need a reformat if the mode has autoindent, while I zoom the window (C-b z) and turn off line numbers to copy out.
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.
Tmux runs in a terminal; use `[` and `]` for my tmux buffer; and the terminals OS Copy/Paste integration when i need to get things in/out. Reading these threads I didn't realize the heartburn they felt with tmux.
For copying text I just hold down shift before click-selecting. Works fine. But if you need to select a long bit of text which scrolls beyond the screen then I use scp or rsync
shameless plug: I wrote a tool to copy text from tmux on remote host to local OS, this is often needed when you ssh into remote host, and want to copy large amount of text (e.g. more than one screen) to local OS
> You can't have it all with the mouse no matter your settings
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):
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.
I couldnt figure out how to get the mouse behavior I liked working in the shell as well as in editors like less or nano. Id get the shell able to scroll and work well with selecting text, then Id have some archaic mouse behavior in my editors. Or I could have the editors working like they do outside of tmux, but then I lose the ability to scroll in the shell and whole tmux multipane window scrolls off screen instead. I could get into the keybinds, but I dont use vim so they are pretty ancient and foreign to me. The effort for me to learn these binds doesn't seem there compared to just moving my windows with the mouse once or twice a day.
> 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.
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.
For me tmux isn't about new windows, it's about keeping a session open when my ssh connection dies, or my vpn resets which causes a connection to die, or any of 100 other things that can happen. Tmux keeps my stuff going while I'm not there, and I can come back to it.
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.
The top reason I did start using tmux was because of how you can select text with the keyboard in copy mode (like visual in vim mode). Then I got the plugin tmux-plugins/tmux-yank which adds "y" command to copy the text. Also works with selection by mouse.
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.
> The top reason I did start using tmux was because of how you can select text with the keyboard in copy mode (like visual in vim mode). Then I got the plugin tmux-plugins/tmux-yank which adds "y" command to copy the text. Also works with selection by mouse.
Sure, but this is the internal "copy mode" of tmux, and is not useful to copy text in and out of your terminal.
You can configure tmux to synchronize with the X clipboard, although it is somewhat fiddly because of how terminal emulators work. See this page: https://github.com/tmux/tmux/wiki/Clipboard
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.
> 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.
No, this is not how it works. There is no terminal emulator that offers this kind of fine-grained mouse support. tmux can either turn the mouse on and handle everything (resize, scroll, copy and paste) itself, or it can leave it off and receive no mouse events.
tmux has no direct access to the X clipboard itself. Reading the clipboard with OSC 52 is possible but it is unfortunately not widely supported by terminal emulators (you can do it with `refresh-client -l` if the terminal emulator supports it).
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.
No, it's not the internal "copy mode" of tmux, it's integrated with xclip (or xsel) so works via the normal clipboard I'm using in other applications too, it's basically the entire point of the tmux-yank plugin and why I shared it.
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 could understand if you don't like tmux for other reasons
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?
Middle-click I don't know about, as I never use it. Usually I don't even have a mouse connected to my computer so I'm limited to a keyboard only. I use the provided `yank` (prefix+y by default) to copy and normal ctrl+shift+v to paste in terminal. Then in other applications I just use ctrl+v and ctrl+c normally.
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.
This is little to do with tmux and much to do with the features offered to terminal applications by terminal emulators. Both clipboard and mouse support in terminals generally is quite limited. For the clipboard, this page documents how to configure it within the limits of what is possible: https://github.com/tmux/tmux/wiki/Clipboard
That's the main problem with tmux in my experience, whenever I open an issue or a feature request on tmux github, the devs say it's a terminal issue. I then open the same issue on the terminal github and the devs there say it's a tmux problem.
Perhaps 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.
With my config a normal highlight interacts with tmux and if I hold shift it interacts with my terminal emulator. I'm using Termite, but I swear it worked the same in others like terminator and urxvt as well.
I have both a local and remote tmux session and am basically exclusively using shells in tmux, so I've long since gotten used to in.
This must be fairly standard, because a friend of mine uses Hexchat on Windows where a normal highlight can grab a line from IRC, but without the timestamp. Holding shift lets you grab all the actual text, timestamp included.
it works pretty well if you're in vi mode, because the same key commands are used in vim for visual mode. so you end up just getting used to scrolling that way.
Tmux on my local machine was useless. Tmux on my server has been a godsent. Just connect and re-attach to the tmux session and you are right where you left off.
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.
I guess different work patterns work differently for different people. I've been using tmux exclusively on my local machine (much less often on remote machines) for the last 2+ years, and it really works well for me. On a daily basis I tend to work in a lot of different contexts, so having scroll-back buffer and bash history nicely organized so I can switch from task to task, with clean restoration of the scrollback/bash history for each environment when I reboot my computer to update it is a godsend. I also like having the various parallel running tasks for a particular environment (like an ssh, log tail, commands) - all running in different panes in a single window - so I never have to go looking for them.
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.
"Tmux on my server has been a godsent." Exactly. I let my cloud VM tmux sessions run for months. I manage other VMs and Docker containers from my tmux "command center".
I use a terminal multiplexer (happens to be screen, but could as easily be tmux) to manage local contexts. A fresh terminal in the same context is then just three keys away. The contexts drive a number of things, but most importantly I set BASH_HISTFILE so each has its own history. I love it, but of course ymmv.
I'm using tmux on server and putty to connect and it works for me. I don't really configure anything, just `set-option -g mouse on`. Mouse scroll works (emulated by tmux, but good enough for me). To copy, I'm using shift+left click drag (standard Putty hotkey), to paste I'm using shift+insert.
Can someone please please make a util that configures tmux for me?
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?
Necessity is the mother of invention. But I think you'll find that when you start writing something like that, you'll eventually learn enough about the config format that you'll no longer need a wizard to create the config for you. Then, it becomes hard to work on the wizard, because the necessity aspect is gone.
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.
Oh so many useful utilities to write. Folks often say "what should I do with my programming skills?" when there are endless tools, whos lack hold us back.
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 you build it yourself you could easily continue those contracts with way less work put in. There's many, many jobs out there that exist only because people don't think they can read the documentation and figure out how to run things themselves.
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.
Only if he’s a freelancer. If he works for a company, they could just take this piece of work product that he made, use it in all the ways your just described, and then lay him off.
If they write it in their free time, they could offer to sell it to their company for 2x yearly salary or something. Got a buddy that has done that 3 jobs in a row.
Depends on your contract. It’s not uncommon (or even necessarily unreasonable if you’re a full time employee) for a contract to stipulate that any code you write during the period of your employment that you make use of at work is owned by your company. I would imagine there are exceptions to this - I don’t think an employer could make a case that they own your Emacs scripts if you use them both at home and at work, and they certainly couldn’t try to take ownership of your side hustle that has absolutely nothing to do with your job - but for a fairly niche tool which produces value at your job, I think they’d be at least trying their hand at holding onto the IP if/when you leave, and restricting you from selling it on the side while you’re still employed. Probably also depends on the culture at your workplace and how decent your managers/bosses are.
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.
No, it wouldn't. Your examples are mostly hints that it's actually your terminal emulator (which might also serve as your "SSH program" in cases like PuTTY) which might need a slap to behave correctly - and then your TERM environment variable and possibly LANG (UTF-8 support) should be set up correctly. tmux will work then.
A util like I propose would be able to 1) ask what term / ssh you're using, 2) ask you to demonstrate keystrokes and mice and determine if they're working, 3) offer suggestions for how to fix them.
Yeah I always wonder why devs for such popular programs don't pause dev for a while and generate such utilities. Clearly they have the skills to do it if they can write tmux.
After a few years in tmux, I actually moved back to just iterm2 (I'm always on osx). There are many new Iterm2 features over the last few years that make tmux unecessary IMO.
- 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.
Don't forget about iterm2's tmux integration. It makes both local tmux and tmux over ssh appear like regular tmux panes. No more bizarre keybindings and tmux configs - it just works.
> 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.
If you're disconnected from the server while some program is running, this program will receive HUP signal. I don't really like this fact and that's the only reason I'm using tmux for any important programs.
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.
They are local projects, but you can be ssh'd into another server from a tmux session / window. A tmux window or split window is just another terminal at the end of the day.
Having them remote also saves you from the window-update-hell, which annoys me no end. You can save the session and log out.
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.
> Having them remote also saves you from the window-update-hell, which annoys me no end. You can save the session and log out.
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.
Absolutely, it's invaluable for just this feature. Also for digital nomad type workers who often have inferior internet to work with, and for being at the same exact spot when you left the office and get home to wrap up that last bit of work. Just reattach session and keep going. I also like to keep a freenode pane open that stays relatively uninterrupted.
So I predominantly use Macs. The one and only reason why I personally use tmux is because of tmux -CC. I never bothered with screen/tmux simply because I didn't want to learn another whole new set of keybinds (let alone reconfigure them). tmux -CC largely behaves as a native app. Want a new tab? CMD+T. New window? CMD+N. Scrollback with the trackpad. That sort of thing.
The complete system is iterm2 + tmux -CC + et (EternalTerminal) for persistent ssh connections.
How is the behavior in et compared to setting up a no kill signal from your ssh config? Sometimes my no kill signals get killed after a half hour or longer.
Hi there! I'm the author and maintainer of Byobu (byobu.org) here. Byobu started as "Screen for mere mortals", but eventually pivoted to work with Tmux, as well. Nowadays, Byobu is much more tightly tied to Tmux. You can think of it, as a super opinionated set of Tmux settings, easily portable across all of your machines. Happy to answer any questions here!
As a byobu user, the only difficulties I've had getting it working was when I tried to get it on Android/termux, which doesn't provide Python/etc packages through apt (default termux repos also don't provide gcc). It works fine for me on fedora and other full distros. As far as working well, byobu doesn't work well on windows WSL1, but I think that's more related to the process model being different and the missing (filesystem, init) functionally for status bar applets.
(Author of Byobu here) Byobu does run "best" on Ubuntu + Gnome-Terminal + Tmux, mainly because that's the primary environment in which I test it. However, I and others have ported and used it on many other Linux and Unix systems, and I'm always happy to take bug reports and patches that fix issues on other OSes.
What this author has settled on looks very similar to commonly used tiling window manager shortcuts (which should not be very surprising, because a lot of the constraints desired by the author apply to the other situation also). In fact, even more directly, the author is basically using TMUX as a the tiling window manager for their terminals. So, 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 :-)
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).
Portability and accessibility do work in tmux's favour which a tiling window manager (I was on ion3 for ages) cant emulate. I probably have a weird development style but with tmux/ssh and the same session I can..
* 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.
> What this author has settled on looks very similar to commonly used tiling window manager shortcuts
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.
Yes, and there are a number of other configurations doing the same. This is another recent one https://github.com/jabirali/tmux-tilish that works as a tmux plugin.
I think this is very common for tmux usage in general. I think the reason is that terminals seem to benefit the most from tiling WMs, as generally their own internal window management is quite lackluster and you usually want to open many terminals side by side. If you don't have the luxury of a tiling WM (or just want a simple-no-yak-shaving-required WM like Gnome), then tmux can be a real life saver.
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.
A great feature of tmux is that every action can be automated from the command line using commands such as split-window, resize-pane, and select-layout. With the send-keys and capture-pane commands you can even automate interacting with any process running inside tmux. The man page provides a good overview of these commands. There also exists a wrapper for Python [0] and I'm currently working on one for R [1].
Tmux is what makes Linux worth it for me. Or more specifically, the command line. It is incredibly freeing, and discovering it is what made me finally choose the sysadmin path over outright programming.
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.
I have honestly never seen any big value in using tmux over screen. I do all the multiplexing in my window manager and I use tilix which allows me to sync commands over multiple sessions.
I used screen for like 10-15 years. Two years ago, I switched to tmux because of some rough edges with screen. I can't remember what they were now, I think something to do with selecting the correct terminal type (TERM=screen? TERM=xterm-256color? TERM=screen.xterm-256color?). Something went wrong, and I couldn't fix it.
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
tmux has been around for as long as I've been using a CLI daily and both tmux and screen have the same overhead for installing from a package manager. I'm not using tmux over screen: I'm just using tmux.
Am I missing anything if I’ve always just logged in somewhere and used Emacs within screen? I get to use all the navigation, window management and clipboard commands I’m used to. Very rarely I’ll need to fire up ansi-term which is slightly less integrated I guess.
Nice to see somebody else go through the exact same thought processes I did - there's no need for tiling when everything other than the terminal is fullscreened on its own workspace. 2D workspace grids are crucial to this flow though, which is sadly something that seems to be slowly being removed from most desktop environments. I can recommend https://extensions.gnome.org/extension/1485/workspace-matrix... for Gnome.
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).
This is really helpful. I hadn't thought about adding bindings that work without shift. I just tried this and had to escape the slash to get the second binding to work:
That’s it right there. I basically have the same thing. Worst comes to worst, Since they are visually so close, when I started, I never forgot what did what.
I was born in France, so grew up with one of the weirdest ISO layout: "AZERTY".[1]
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.
I wanted to chime in and revel in your company... Something similar (but never as bad as your painful description of AZERTY) happens with Spanish keyboards, and there are even varieties for different Latin American countries. As you mentioned, I finally found ever lasting peace when I switched to an ANSI-US keyboard, and never looked back. Thankfully my current employer defaults to these keyboards; it used to be a chore to provision them some years ago.
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?
Honestly, for me the split keys are just muscle memory at this point, same as 'hjkl' in Vim. Same with my prefix- I used backticks for the longest time, and now I use Ctrl-Space, but I generally don't think about it anymore. (Along the same lines, I screw up and occasionally type "jj" or ":wq" in message boxes out of force of habit from Vim.)
It'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!
> I screw up and occasionally type "jj" or ":wq" in message boxes out of force of habit from Vim
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.
I spend a lot of my time using VIM. About 6 months ago I started using tmux. I can honestly say I love it. It was a little rough at first but I just made a cheat sheet on a piece of paper the size of a business card. That helped a lot. The default keys start to feel okay just like with VIM. I don’t have any problem with people customizing tools however they want so this post is really great. Anything that lowers the barrier for entry and or improves things is great.
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.
People do seem to often complain about the tmux defaults or say their particular configuration is "sane" and the defaults are not. But if you look at changes people make or at requests made over the years, they are all over the place and there is rarely a single common consensus on how the defaults could be better. Even if you look at something like "tmux-sensible", it is maybe a dozen lines of changes, of which some are now obsolete, some have downsides that prevent them being the default , and some are obviously personal preference.
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.
I see he generically refers to "the mod key" but I don't see anything declaring what the mod key should be like you would in a tiling wm config, so I'm assuming the M- is the meta key in all these keybinds then. I wish that had been made more clear. I was pretty curious the whole time I read the article how he'd changed C-b to something else and what he'd picked.
I had also briefly wondered if he'd somehow made things modal like vim so he could enter some sort of "tmux mode" where he could just press a key for an action and then return to his insert mode after. (also a bit like i3/sway's modes, the most common one being for resizing windows)
A lot of people seem to think tmux is a replacement for a window manger which IMO isn’t quite right.
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.
These days I dropped tmux for vim :term (panel for files/terminals; tabs for workspaces). If I'm in a remote server and want to preserve the session, I just use screen.
Now would be a cool time to remark that VSCode is adding tmux control mode support (As of yesterday it was added to the backlog) [0]. This will be very useful in persisting terminals.
That's the only thing I envy from the VI/Emacs/tmux world is that the editors and terminals can work in the same window in the same spot of the screen and it looks seamless.
IMO these are the most important tmux config directives.
# 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.
Tmux is amazing, my only request is there be an option to name panes (with the names showing perpetually on top or bottom of the pane). Every time I ssh into an ec2 instance I can't remember what logs are showing in each pane!
You can do this. Turn on pane status lines (set `pane-border-status` option to `top` or `bottom`). You can then change `pane-border-format` to contain the text you want. It can show the application-set pane title (`#{pane_title}`, also settable with `selectp -T`) or anything else really.
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}`.
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).
I have to say I spent some time on my tmux config, but the result is just awesome. I have key bindings to search/select/copy text and have integrated the mouse fully and can copy/paste between all windows and other apps (such as firefox etc.) perfectly. I find tmux an incredible tool.
All I use tmux for is to reattach to sessions after a connection drops. The rest I just configure away as much as possible, but not quite as much as I want. Is there any simpler utility that only provides persistent sessions?
Having tried tmux this week (I'm a screen diehard) and had it entirely disconnect and lose the session without warning because I pressed ... some key combination I have no idea what ... I've put that back into the "eh, maybe" pile for another 5 years.
Hmmm... I would find this extremely error-prone. Probably due to my own issues, but flipping through multiple remote sessions in tmux in the same window would get confusing after N=2 terminals.
But who manages THAT many remote sessions? Seems like an upstream problem to me, no?
I always want to emulate my seemingly-more-efficient colleagues. One of them had a set of 6 sessions in some layer talking to screen which was talking to vim or XXsh (bash, zsh, or something), and he had memorized an arrangement whereby he could think "I'm in this one and I want that one" and he'd go left-left or right-up and be in the right one. But he always had one unused when I would visit him and would pursue a search in that one. None of this was remote by the way. This inspiration got me to try screen but I didn't like it after all. It in no way inspired me to run Vim because I already preferred Emacs.
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.