So you’re using iTerm2 terminal emulator on OSX. And you’ve heard about tmux, and decided to give it a try. Google here, Google there, after a while you grasp concepts like terminal multiplexing, windows, pane splitting, and understand tmux usage on remote machines to persist session state and survive abrupt disconnections.

At some point of time, you might wondering about tmux usage locally.

“Given iTerm already can create multiple virtual windows inside a single ‘physical’ window, can split, swap and resize panes, do I really need to use tmux on my local machine instead of iTerm?”

When I was learning tmux, I had been returning to same question again and again. It was not clear without some practice. So I’ve decided to give it a try, and today I can share benefits and drawbacks with you.

iTerm2 vs tmux on local machine: benefits and drawbacks

Benefits:

Named windows. Similar to tabs in iTerm, but you can give them a name

Similar to tabs in iTerm, but you can give them a name A status line with system-wide information. Includes CPU, memory, online/offline status, battery, user, host, and date time.

Includes CPU, memory, online/offline status, battery, user, host, and date time. Having status line and set of named windows inside it, I can turn iTerm to full-screen mode. This which allows me to work in a distraction-free environment and also get extra 3 rows. These previously were taken by OSX menu bar, iTerm window frame and iTerm tabs row.

and also get extra 3 rows. These previously were taken by OSX menu bar, iTerm window frame and iTerm tabs row. Monitor window for activity or silence. When I run a long-running command in one pane, I can switch to another pane and be notified when no more output appears in previous pane for some interval

iTerm has something similar, but it’s only about notifying you when execution returns to command prompt, and requires installing extra shell integration

When I run a long-running command in one pane, I can switch to another pane and be notified when no more output appears in previous pane for some interval iTerm has something similar, but it’s only about notifying you when execution returns to command prompt, and requires installing extra shell integration Redefined panes layouts. Even-horizontal, even-vertical, main-horizontal, main-vertical and tiled

Even-horizontal, even-vertical, main-horizontal, main-vertical and tiled Ability to switch between several per-project local tmux sessions to easily switch context

to easily switch context If you’re using tmux both locally and on remote machine, you’d get the same familiar terminal environment

When you’re using tmux, you rely on iTerm2 unique features much less

This makes it easier to migrate to a different terminal emulator, be it on same OS or another one (Linux)

Drawbacks:

tmux maintains it’s own scrollback buffer. It’s more difficult to access it and copy text than in iTerm (just scroll and select with mouse)

It’s more difficult to access it and copy text than in iTerm (just scroll and select with mouse) If you copy text in tmux, it’s stored in tmux own buffer, and not shared with your OS clipboard by default. To be 100% correct, sharing with system clipboard works in iTerm2, but just because it supports OSC 52 ANSI escape sequences that let application such as tmux to access and store data in clipboard. iTerm2 is a special case. Just try to copy text in tmux running in OSX default Terminal, which does not support OSC52

To be 100% correct, sharing with system clipboard works in iTerm2, but just because it supports OSC 52 ANSI escape sequences that let application such as tmux to access and store data in clipboard. iTerm2 is a special case. Just try to copy text in tmux running in OSX default Terminal, which does not support OSC52 If you’re already accustomed to iTerm keybindings, you need to learn and switch to tmux keybindings, which are cumbersome. Instead of single keystroke like ⌘⌥->, you need two keystokes: prefix followed by another key, mapped to specific tmux action.

Personally, I decided to go ahead with tmux and its features, and rely less on iTerm2 specific features. Indeed, right now I’m using iTerm just as a tunnel to tmux 😄

Issues with scrollback buffer and integration with OS clipboard are highly vital, that you can even decide to give up adopting tmux. We’ll address these topics in my future posts.

Override iTerm key mappings to trigger tmux action

Today, let’s see how we can use familiar iTerm keybindings while working in tmux environment. The idea is to map keystrokes in iTerm to trigger tmux actions.

The easy way would be just to go to .tmux.conf and map tmux actions to those keybindings. For example, to resize pane in iTerm, we use “ ^⌘↑ ”, let’s map the same keystroke in tmux in somewhat naive way:

bind ^⌘↑ resize-pane -U

However, the code above will not work because you cannot use ⌘ in tmux keybindings, and SHIFT usage is also very limited. And even it that was possible, iTerm would intercept that keystroke before.

Instead we setup new iTerm profile, and override key mappings to send pre-configured sequences of bytes, that will trigger corresponding action in tmux.