The declarative nature of having a YAML/JSON config that consistently abstracts out the commands you'd make. It prevents the mistakes and repetition scripting t

The declarative nature of having a YAML/JSON config that consistently abstracts out the commands you'd make. It prevents the mistakes and repetition scripting tmux entails. In addition, there's no need to worry about shell scripting portability across systems. I personally use macOS, Linux and BSDs, so I have to take extra time to ensure my scripts work on machines without Bash. For some shortcuts, tips, and tricks on tmux, I have a section in a book I've recently published at https://leanpub.com/the-tao-of-tmux/read#scripting-tmux https://leanpub.com/the-tao-of-tmux/read#scripting-tmux. It's freely available online. It covers command aliases, pattern matching, targets and formats. > Side note: tmux has an annoying misfeature that panes can't be named nor does their numbering stay stable. It's a bit tricky to programmatically set up a bunch of panes (can't do `tmux split-window -t mysession:mywindow.mypane` The internal pane_id stays the same. If you're using a library like libtmux (https://libtmux.git-pull.com https://libtmux.git-pull.com), you can keep reference to the pane after split-window commands and stuff. > So to get a specific layout, you need to do all your splits in a specific order. Yes, this is one of the reason tools like tmuxp, tmuxinator and tmuxomatic exist. tmuxp goes the extra mile and has integration tests across a matrix of tmux versions to assure complex configurations produce the intended result upon loading a session. (https://github.com/tony/tmuxp/tree/master/tests https://github.com/tony/tmuxp/tree/master/tests) Writing those tests took time, but were highly worth it when minor changes in the behavior of tmux popped up across versions.