Imagine this: I can contain all my rails processes inside a session named 'rails_project' and all my node processes in a session named 'node_project'. This also causes a grinding halt to your workflow. When you start mixing tabs from completely unrelated tasks without clear boundaries, you can't tell which tab is for what. At some point, you'll start asking, 'which of these 6 tabs did I just run the jest test?' or 'which of these two Vim tabs was my rails codebase?'.

Although that would work, this could cause tab chaos. To be fair, you could argue that you could just open more tabs for node tasks instead of killing the previous rails processes. What if instead of killing those rails-related processes, you can 'put them aside' (while they're still running), run whatever processes you need to complete your node task, then return to your original rails-project task as if you never left? That would be nice, wouldn't it? Tmux lets you do just that! This context switch causes a grinding halt in your flow. Without tmux, I would probably stop the rails server, close vim, and exit the mysql server before starting the node-project task. Then someone asks you to debug a completely different node project.

For example, suppose that you are running a rails server, vim editor, and a mysql console in the middle of a rails workflow. Before you get perPLEXed by the phrase Terminal MUltipleXer, I'll explain what it means.Ī terminal multiplexer lets you to leave a terminal in the middle of a process and return to it seamlessly. Once you started using Tmux, you will ask yourself why you have not used it until now.Īccording to man tmux, Tmux stands for 'Terminal MUltipleXer'.

Tmux switch panes