Comment by submeta
1 day ago
I love tmux in combination with tmuxinator. Because with one command I can start my dev setup with one split for nvim, one for lazygit, one for yazi and one for claude code. In another window I can run the server, in another I can tail the logfiles.
I have similar setups for various projetcts and do not need to manually start services, tools, whatnot. With `mx projectx` everything is started within seconds.
And navigating panes and windows is super easy with the proper shortcuts (opt+h,j,k,l), even across tmux and nvim.
Why would I give up on that?
Thanks for the link to tmuxinator, I had heard of it but never learned what it does. I think I'd like something like this. But I think this is a case of tmux providing a platform, I think the core idea of tmuxinator could be implemented outside of tmux, so tmux in that regard is basically an implementation detail.
Then it is a pragmatic decision, using tmux you get to use the ecosystem of things like tmuxinator which explicitly target tmux to get a known number of terminal features like splits. What I learn from the OP, is that there are technical reasons that tmux is not a "good design" - like Kovid's comments on how it constrains innovation in terminal designs - which might lead someone to consider, what actually does tmux do and could my workflow be implemented otherwise?
It might be a bunch of unixy hacks and tricks (as another commenter here said) but it can work. I'd imagine recreating something like tmuxinator would be hard though, but it could also be interesting, like having arbitrary GUI programs configured to appear in "splits" using tiling integrated seamlessly within the terminals. But yeah, if the workflow is already set up and serviceable and supported with a community, using tmux, then I'd just keep using it.