I still don't quite understand the value of tmux, at least on a modern machine. If I need another terminal, I just pop open another terminal window and tile or tab it. If I want to keep a set of terminals organized, I use workspaces (at the OS level).<p>I can obviously see its value if there is no window manager or desktop environment on the system I'm using, but that's rare these days–if I'm working on a system with neither of these it's always over ssh. With a WM or DE it seems like tmux just adds a redundant layer of organization. What am I missing?
If you like tmux, take a look at zellij (<a href="https://github.com/zellij-org/zellij" rel="nofollow">https://github.com/zellij-org/zellij</a>), it is a modern alternative that has a lot of nice features (either developed, or on the roadmap) that tmux is missing.<p>Have no relationship to it, just a happy "customer".
tmux sessions are incredibly useful for keeping multiple projects organized.<p>i just wish i could connect to remote tmux back ends and recover windows as organized locally after a network cut.<p>so the local tmux presents the ui and performs session management, and the remote tmux backends hold the shells to provide network cut resilience, but still rely on the local ui instance for all user interaction (so cut/paste buffers and mousing and such are preserved)
I had this problem myself when using tmux (how to switch sessions quickly and easily).<p>I ended up writing a shell script [1] to use fzf to display a list not only of sessions, but the windows within each session.<p>Which I invoke from tmux like this:<p>bind C-a run-shell -b "$HOME/.local/bin/ftwind"<p>This has become so ingrained in my tmux workflow that I would be utterly helpless without it.<p>[1]: <a href="https://github.com/anelson/dotfiles/blob/master/home/.local/bin/ftwind" rel="nofollow">https://github.com/anelson/dotfiles/blob/master/home/.local/...</a><p>EDIT: for formatting
If this tmux-fzf setup could be augmented to perform preview and grep not only on window name but also window contents then I'd consider migrating from the already built-in `choose-tree -Zw` command.
I'm still trying to assemble a way to put together the pieces to not only return to tmux sessions after detaching, but after detaching <i>and the underlying server reboots</i>. Playing around with CRIU, but trying to make it all automagic with nested PIDs, restore the screens and shell history buffers just how I left them, and implement the common use case of automatically re-establishing ssh connections remains a challenge.
Another reason for using tmux: never worry about changing your muscle memory for splits and nav ever again.<p>I've been using tmux for five or six years. In that time I've used Linux and MacOS and several different terminals. But how I navigate around a terminal has stayed the same thanks to tmux.<p>Another reason: put complex tmuxinator configs in source control and start up a bunch of stuff for your project with a single command.
Once I discovered fzf a couple of years ago, I instantly knew it was the future of shell. My entire workflow is now driven by fzf. I use it together with bash, vim, cd (and "z" command), even mkdir (autocomplete from "words" file).
I've a much simpler solution. I nest tmux sessions. In the top-level session every window is named the same as the session that is attached in it. I've two different prefix keys: ^T for the top-level, and ^A for the level below. Plus I've a one-liner (well, shell function) for mapping PIDs to session & window. Plus a script to create new nested sessions, and a script start $EDITOR in a window of the current session (with the window named after the file being edited). Plus I've a half-baked script to set up this environment, with one nested tmux per-project.<p>This allows me to have a very well-organized way of working over ssh.
I really like iTerm2 for Mac. The tabs, splits, and navigation, are intuitive and powerful. I haven’t found a need for tmux. I use fzf for file finding, it looks like this is use is a subset of iTerm2 capabilities
It is interesting how much people use tmux for working in several interactive shells at once. I tend to use tmux more for running servers in detached windows.