Best Practices: Idioms, Habits, and Knowing When Not to Use tmux

This chapter distils the habits worth building, the anti-patterns worth dropping, and the moments when the right move is to close tmux and open something else.

Habits Worth Building

Name everything

Sessions, windows, both. Named targets are easier to reattach to, easier to script, and easier to read in tmux ls output. Numeric indices are fine for throwaways; anything you'll still have tomorrow deserves a name.

tmux new -A -s api                              # session: api
<prefix> , editor<Enter>                        # window: editor

Detach instead of exiting

When you're done for the day, detach. Don't exit every shell to close out. Detach is one key; exit is tedious and kills background processes. Next morning, tmux a -t api and you're right back.

One session per project

Resist the urge to keep everything in one giant session. One session per active project scales better:

  • api: the backend project
  • frontend: the web UI
  • reading: long-running books, docs, man pages

Switch between them with <prefix> s. Archive done ones with tmux kill-session -t name.

Learn one thing a week

Like vim, tmux has a deep tail. Pick one piece a week: a new binding, a new format string, a plugin. Force yourself to use it for the week. Keep what sticks.

Candidates:

  • <prefix> q and its number jumps
  • <prefix> w for the tree picker
  • <prefix> { and <prefix> } to swap panes
  • Copy mode searches you haven't tried
  • A new hook
  • The tmux-resurrect restore key

Script the repetitive setups

The second time you set up the same layout by hand, write a script. By the third, the script is already there. A hand-written bin/start-api that takes three seconds saves you ten seconds a day for the life of the project, and it's always correct.

Reload config binding

bind r source-file ~/.tmux.conf \; display "reloaded"

Essential. Without a reload binding, iterating on config is a pain. With it, you can tweak bindings and see the effect in seconds.

Anti-Patterns

Hoarding unused sessions

You start a session to try something, detach, forget about it. Six months later tmux ls has thirty sessions. Most are stale.

Clean up. tmux kill-session -t old. Or periodically:

tmux kill-server

Start fresh. You don't need tmux itself to persist between your ideal workflow sessions.

Over-configuring the status line

Status-line theming is the biggest time sink in tmux-land. You can spend a weekend tweaking colours and nothing about your work improved. A clean, minimal status line (chapter 8) looks professional and loads instantly.

A rule: spend an hour on the status line once, then never again for a year.

Plugin bloat

Every plugin costs startup time and complexity. Three to five well-chosen plugins are better than twenty half-used ones. Prune quarterly.

Nested sessions by accident

You SSH to a remote box from a tmux pane on your laptop. The remote box has a shell. You type tmux out of habit. Now you have tmux-inside-tmux with the same prefix, and nothing works right.

Either use a different prefix remotely, or adopt the F12 toggle pattern (chapter 11), or just don't nest when you don't need to. The outer tmux gives you pane splits and persistence; you rarely need both layers.

Mouse-first navigation

tmux's mouse support is nice. Relying on it for everything defeats the point of keyboard-first workflow. Turn mouse on if you like; still learn the keys.

Custom bindings you forgot

You bound <prefix> G to do something elaborate. Six months later you press it by accident and can't remember what it does. Every binding is a memory cost. If you haven't used a binding in a month, delete it.

Idioms Worth Stealing

A short list of patterns that come up constantly:

tmux new -A -s name              # create or attach
tmux a -t name                   # attach, exact match preferred
tmux ls | awk -F: '{print $1}'   # list session names only

# alias for one-keystroke attach/create
alias t='tmux new -A -s'
<prefix> s                        session picker, interactive
<prefix> w                        window tree, interactive
<prefix> z                        zoom the current pane
<prefix> q                        show pane numbers briefly
<prefix> ,                        rename window
<prefix> $                        rename session
<prefix> d                        detach
<prefix> [                        enter copy mode
<prefix> ]                        paste buffer
# inside copy mode (vi)
v                                 start selection
y                                 yank to clipboard
/                                 search forward
q                                 leave

Naming Conventions

A convention that pays off:

  • Sessions: lowercase, short, project name. api, frontend, dotfiles
  • Windows: lowercase, role. editor, shell, logs, tests, db
  • Panes: unnamed. Indices are fine. A single window rarely needs more than four panes

Once you commit to a pattern, <prefix> w output is self-documenting:

(0) + api: 4 windows
      0: editor (2 panes)
      1: server
      2: tests
      3: logs
(1) + dotfiles: 1 window
      0: editor

Compare with:

(0) + 0: 4 windows
      0: zsh (2 panes)
      1: zsh
      2: zsh
      3: zsh

The first version takes twenty seconds of naming effort. The second takes twenty seconds of guessing every morning.

When Not to Use tmux

tmux is a terminal multiplexer. It is not the right tool for:

  • GUI apps. It lives in a terminal. If your workflow is graphical, you don't need tmux in the middle
  • Casual terminal use. Opening one shell to run one command? Skip tmux
  • Tiny VPSes with limited memory. tmux costs a few MB per session plus scrollback. Rarely a problem, but on a 256MB box it can matter
  • Environments where installing software is not allowed. If you can't get tmux on a box, learn screen. It's older but shipped by default almost everywhere

tmux purists will keep it running all the time. You don't have to. Use it when persistence, layout, or scripting earns its keep; drop it when they don't.

Becoming Fluent Takes a Month

tmux's learning curve is shorter than vim's. Rough timeline:

  • Day 1: tmux new, <prefix> d, tmux a. You have persistence
  • Week 1: sessions, windows, panes. Split, navigate, resize, zoom
  • Month 1: copy mode, command prompt, a solid .tmux.conf, one script template
  • Month 3: status-line taste, plugins, nested sessions, scripting confidence
  • Year 1: it's invisible. You don't think about tmux any more; you just work

Don't rush. Each layer makes the next one easier.

A Starter Habit Loop

For your first two weeks:

  1. Open a terminal, run tmux new -A -s main
  2. Do all your shell work inside that session
  3. When you close the terminal, detach first (<prefix> d)
  4. Next time, tmux a -t main and pick up where you left off
  5. Once you're comfortable, split into windows per project

That's it. No config changes, no plugins. Get the persistence habit first. Everything else comes naturally once "my shells don't die" is automatic.

Where to Go From Here

  • Read man tmux once, slowly. Skim the second time, search the third
  • Write a session script for your current project
  • Try three plugins. Keep one
  • Read someone's .tmux.conf on GitHub for ideas; steal the two lines you like
  • Check in on your setup every six months and prune
  • Watch a fluent user work. Steal one habit

tmux is small enough to understand fully. Give it a month and it will feel like a natural extension of the terminal you already use.