4 ms·

I hate tmux because the way it handles switching windows is terrible. The model is switching between windows, each of which can have some layout of panes. Thi

by wnoise 6y ago

I hate tmux because the way it handles switching windows is terrible. The model is switching between windows, each of which can have some layout of panes. This is approximately never what I want for a long-running thing I can detach from and reattach to, from a different terminal with different connections. Further, it supports multiple attachments by each having them see the same exact thing. For terminals that are different sizes, it shoves everything into an area the minimum height and width of all attached clients, and displays everything outside that as a field of periods. I really prefer screen's functionality, instead. Each pane can be independently switched to any of the pool of underlying ptys being managed. The exact layout of panes is more of an ephemeral thing. On wide terminals I can split side-by-side, on narrow ones I can split top-above-bottom (and these can even be different for different clients connected to the server). It handles the multiple attached clients by only make I think tmux's model is due to being too closely modeled on GUI virtual desktops. That rant aside, tmux does have some nice features available by default that take a fair bit of configuration to get working well in screen.

flaxton 6y ago
Except that screen is dead :-/
- rhizome 6y ago
  Dead? 4.8 came out less than a year ago and there was a patch less than a month ago. https://git.savannah.gnu.org/cgit/screen.git/ https://git.savannah.gnu.org/cgit/screen.git/
em-bee 6y ago
tmux supports multiple sessions and switching between those. sessions behave independently like your screen windows. you can of course have multiple windows in each session, which then behave the tmux way. you can also have the same window show up in multipe sessions and use that to emulate screen behavior. (i saw a script to help with that some time ago) for me, multiple sessions alone provide enough flexibility.
- wnoise 6y ago
  It probably technically does, in a horrifying Turing-tarpit way. I actually did try to get the behavior I wanted out of nested tmux invocations and a hairy mess of scripts. There was no 'next-session' command (though now it looks like 'switch-client -l/-n/-p' would work. Hmm.) I couldn't get it to work right, only a half-done approximation, and it involved way too many tmux interpositions. Screen: client -> per client view of P panes -> P of entire pool of T terminals in session. Tmux: client -> 1 of S sessions -> 1 of W windows -> P panes To get splitting at the top level I need one top-level tmux client and its associated top-level session managed by one server. It can actually be locked to one window for what I care about. In each of its panes, I need to run another tmux client so as to be able to actually change what final pty each pane will display. And each of these need to be separate sessions, so that I can display separate things in each of them. Each of these separate sessions will generally only have one window, with its implicit single pane. I should, of course, run all of these inner tmux sessions as a separate server from the top one. Now I just have to make restricted keybindings for both the top and inner clients, and make make sure that any binding for the inner clients are replicated as "self-insert" in the top-level client. And remember that there are multiple places I can direct the command-lines (so need two bindings). This results in the top level server having: client -> session -> 1 window -> P Panes -> P clients And the bottom server having: P clients -> T sessions -> T windows -> T panes And this doesn't yet let you have multiple top-level clients attached the way screen does. I'm sure I could eventually sand off all the sharp edges where it doesn't do what I want and make this work. Or I could just use screen.
  - em-bee 6y ago
    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.
neurostimulant 6y ago
> I think tmux's model is due to being too closely modeled on GUI virtual desktops. Yes, using a terminal emulator that natively support tmux control mode (like iTerm2) is really nice because you can easily resize/rearrange the windows and panes via GUI actions, but absolutely suck when you have to reattach using a traditional terminal emulator because you now have to adjust all those windows and panes with keyboard actions.
- antihero 6y ago
  If you use a terminal emulator that supports pointer events, tmux can use those. You generally just need to do: set -g mouse on
wnoise 6y ago
> It handles the multiple attached clients by only make ... by only making the ptys that are visible in multiple clients have the same size.

by wnoise 6y ago

flaxton 6y ago

Except that screen is dead :-/

rhizome 6y ago
Dead? 4.8 came out less than a year ago and there was a patch less than a month ago. https://git.savannah.gnu.org/cgit/screen.git/ https://git.savannah.gnu.org/cgit/screen.git/

em-bee 6y ago

tmux supports multiple sessions and switching between those. sessions behave independently like your screen windows. you can of course have multiple windows in each session, which then behave the tmux way. you can also have the same window show up in multipe sessions and use that to emulate screen behavior. (i saw a script to help with that some time ago) for me, multiple sessions alone provide enough flexibility.

wnoise 6y ago
It probably technically does, in a horrifying Turing-tarpit way. I actually did try to get the behavior I wanted out of nested tmux invocations and a hairy mess of scripts. There was no 'next-session' command (though now it looks like 'switch-client -l/-n/-p' would work. Hmm.) I couldn't get it to work right, only a half-done approximation, and it involved way too many tmux interpositions. Screen: client -> per client view of P panes -> P of entire pool of T terminals in session. Tmux: client -> 1 of S sessions -> 1 of W windows -> P panes To get splitting at the top level I need one top-level tmux client and its associated top-level session managed by one server. It can actually be locked to one window for what I care about. In each of its panes, I need to run another tmux client so as to be able to actually change what final pty each pane will display. And each of these need to be separate sessions, so that I can display separate things in each of them. Each of these separate sessions will generally only have one window, with its implicit single pane. I should, of course, run all of these inner tmux sessions as a separate server from the top one. Now I just have to make restricted keybindings for both the top and inner clients, and make make sure that any binding for the inner clients are replicated as "self-insert" in the top-level client. And remember that there are multiple places I can direct the command-lines (so need two bindings). This results in the top level server having: client -> session -> 1 window -> P Panes -> P clients And the bottom server having: P clients -> T sessions -> T windows -> T panes And this doesn't yet let you have multiple top-level clients attached the way screen does. I'm sure I could eventually sand off all the sharp edges where it doesn't do what I want and make this work. Or I could just use screen.
- em-bee 6y ago
  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.

neurostimulant 6y ago

> I think tmux's model is due to being too closely modeled on GUI virtual desktops. Yes, using a terminal emulator that natively support tmux control mode (like iTerm2) is really nice because you can easily resize/rearrange the windows and panes via GUI actions, but absolutely suck when you have to reattach using a traditional terminal emulator because you now have to adjust all those windows and panes with keyboard actions.

antihero 6y ago
If you use a terminal emulator that supports pointer events, tmux can use those. You generally just need to do: set -g mouse on

wnoise 6y ago

> It handles the multiple attached clients by only make ... by only making the ptys that are visible in multiple clients have the same size.