well if you want an exact emulation of screen behaviour, sure, that may be difficult. but i think you are making this a bit to complicated.
if what matters is that different clients can look at different windows, then using multiple sessions with one window each will get you exactly that.
you may of course need to get used to tmux way of switching sessions (which is not different than tmux way of switching windows). however, i just checked, there is a command to switch to the next session, and you can bind that to a key. add another keybinding to create a new session, and that should get you to about 90% of your expected behaviour without nesting tmux.
That last 10% matters. I absolutely need split windows, and being able to switch what is in the sub-panes easily. That's what require nesting.
The fact that it also doesn't have my preferred behavior for multiple clients connecting is just a minor nit-pick at that point. And I did say that the misnamed 'switch-client' would likely work.
Tmux has some very nice features: a nice commmand language, xterm-style mouse support, including both event binding and sending to client (pass through only), well thought out client-server separation, the ability for other programs to fairly easily drive it, visual identification of panes, menu-popups, and the default status-line is nicer.
All of that is merely nice to have, not actually needed though. It fundamentally doesn't have a model that works well for me. I wish it did, or that screen gains such things.
> That last 10% matters. I absolutely need split windows, and being able to switch what is in the sub-panes easily. That's what require nesting.
That could be solved by not relying on tmux for splitting, but on a terminal that has that feature, one ssh+tmux connection by panel.
In any case, it seems that you have put a lot of thinking about this, and probably already considered this solution.
I've been in the situation of trying to make my workflow perfectly fit in my new software/os/laptop/etc and not being able to make it work 100%. It's... sometimes exhausting. Nowadays I take another approach: make it fit well enough.
> well that would be like putting two terminals next to each other.
Pretty much! Not a perfect solution for sure.
I used to only rely on tmux, but nowadays I often prefer opening more terminals windows. I found out that by overly relying on tmux, I kept opened a way too high number of shells (browser tabs, anyone?).
Now for most tasks I open a terminal without tmux, that way I'm forced to close it if I don't want to have a cluttered desktop (I never minimize or hide windows, I don't even know how to do it on my wm).
> so you want each of the split windows behave like its own session or something, and switch terminals within that freely.
Exactly. Or at least that's one way to describe it, though it might also equally describe other things.
> so how does screen do that?
It's screen's native model.
'C-a |' (split -v) splits side-by-side and 'C-a S' (split) splits top-and-bottom. Screen calls these "regions". 'C-a X' (remove) will remove the current region, letting the sibling take the entire space again. 'C-a Q' (only) will replace the entire layout with the current region. 'C-a tab' (focus) will jump to the next region (it can take directional arguments to move up, down, left, and right, as well as 'prev' to go the opposite way of 'next', but these are not bound by default).
What tmux users would normally think of as window changing commands just switch the current region in the layout between viewing the entire pool of running commands.
if what matters is that different clients can look at different windows, then using multiple sessions with one window each will get you exactly that.
you may of course need to get used to tmux way of switching sessions (which is not different than tmux way of switching windows). however, i just checked, there is a command to switch to the next session, and you can bind that to a key. add another keybinding to create a new session, and that should get you to about 90% of your expected behaviour without nesting tmux.