tmux and Emacs: settling the keybinding war

Run Emacs inside tmux with the stock configuration and you hit the problem within about four seconds. tmux's prefix key is C-b. In Emacs, C-b is backward-char — one of the six or seven keys you press most in any editing session.

So every tmux command now begins by moving your cursor one character left, and every attempt to move left now opens a tmux prefix that swallows whatever you type next. Both tools are behaving correctly. They just want the same key, and the collision is on a binding neither side can reasonably give up.

Not C-a

Every tutorial says rebind the prefix to C-a. That advice is inherited from GNU Screen, whose prefix was C-a, and it is fine if you are a vi user.

For an Emacs user it is strictly worse than the problem it solves. C-a is move-beginning-of-line, which you press more often than backward-char — and it is also readline's beginning-of-line in every shell you will ever type into, so you break bash and psql and the Python REPL at the same time.

Pick a prefix against actual criteria instead: rarely used in Emacs, rarely used in readline, reachable without contortion, and survives the trip through your terminal emulator intact.

C-o is the one I settled on. open-line is a command most Emacs users could not describe without looking it up, and the key sits under your left hand without a stretch. On a Danish keyboard C-\ is more awkward than it looks in that table, which is worth knowing before you commit.

Whichever you choose, bind it to send-prefix as well, so pressing it twice passes the literal key through to the application underneath. That gives you the original binding back at the cost of one extra keystroke, on the rare occasion you want it.

Tell tmux you are an Emacs user

tmux has an entire vi-versus-emacs switch that most people never touch, because it usually guesses from your EDITOR environment variable and the guess is often wrong. Setting it explicitly gives you Emacs motion inside tmux's own interfaces — copy mode and the command prompt — so C-Space starts a selection and M-w copies it, exactly as your fingers expect.

The escape-time bug that isn't a bug

This one deserves its own section because it is the single most common "Emacs feels broken inside tmux" complaint, and the cause is entirely non-obvious.

Terminal Emacs sends Meta as an ESC prefix — M-x goes down the wire as ESC followed by x. tmux, meanwhile, needs to distinguish a real Escape keypress from the start of an escape sequence, so after seeing ESC it waits to see what comes next. The default wait is 500 milliseconds.

The result is a half-second stall on every Meta keypress in Emacs, and intermittently a dropped one. It reads as Emacs being sluggish, or your SSH connection being bad, and no amount of Emacs configuration will fix it because Emacs is not the thing doing it. Set escape-time to 0 and it vanishes.

A configuration that stops the fighting

# A prefix that does not collide with Emacs motion
unbind C-b
set -g prefix C-o
bind C-o send-prefix

# Emacs keys in copy mode and at the command prompt
setw -g mode-keys emacs
set -g status-keys emacs

# Do not stall on the Meta prefix
set -s escape-time 0

# Colour that matches what Emacs expects to find
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256col*:Tc"

# Splits with Emacs' own mnemonics
bind 2 split-window -v
bind 3 split-window -h
bind 1 resize-pane -Z
bind 0 kill-pane
bind o select-pane -t :.+

That last block is the part worth stealing. Emacs already has a window vocabulary — C-x 2 splits below, C-x 3 splits right, C-x 1 makes one window fill the frame, C-x 0 closes this one, C-x o moves to the next. Rebinding tmux's pane commands to the same digits means C-o 3 and C-x 3 do the same thing at two different layers. You stop maintaining two mental models and start maintaining one.

The resize-pane -Z on 1 is the closest tmux has to delete-other-windows: it zooms the current pane to fill the window, and pressing it again restores the layout. Not identical, but the same instinct — "just show me this one" — reaches for the same key.

The question underneath all of this

The configuration above makes the two tools coexist. It is worth asking whether they should both be splitting things in the first place.

Real friction in a tmux-plus-Emacs setup almost never comes from the prefix key. It comes from nesting: a tmux window split into three panes, one of which holds an Emacs frame split into two windows, so "go to the pane on the right" is C-o o or C-x o depending on a boundary you cannot see. You end up guessing, guessing wrong, and losing the thread of what you were doing.

The fix is not better keybindings. It is picking one splitter.

Option one: tmux for persistence, Emacs for layout. Use tmux as a single full-screen window per project and never split a pane. Its job is surviving a dropped SSH connection and keeping long-running processes alive — which it does better than anything else — while all layout happens inside Emacs, where you also get windmove, registers, and window configurations that tmux cannot match. The prefix key barely gets pressed, so the collision stops mattering.

Option two: Emacs as the multiplexer. Run emacs --daemon, attach with emacsclient -nw, and use vterm for shells. The daemon gives you the persistence that was tmux's main contribution, buffers replace panes, and the whole conflict is dissolved rather than managed. The cost is real: you have put your terminals inside your editor, so an Emacs hang takes your shells with it, and detaching from a remote machine is less bulletproof than tmux detach.

I run option one. tmux keeps the session alive, Emacs owns everything on screen, and the prefix is something I press a dozen times a day rather than a hundred. But option two is coherent, and either beats the middle ground where both tools split things and you spend your day arbitrating between them.

Which is the real conclusion here. The keybinding war is a symptom. You can negotiate a ceasefire with six lines of config — and you should, because escape-time alone is worth it — but the war ends properly when you decide which tool is in charge of the screen.