[db48x]

The first problem is that most of that is a result of how the remote computer handles the programs you were running. When your connection drops, all of them die immediately.

Second, terminals have state. That state must be synchronized between the program you are running on the remote computer and the terminal on your local computer, or the display will be garbled. Even something as trivial as the cursor position is important. If you disconnect, then your program prints something or moves the cursor, and then you reconnect, whatever it did has been lost and whatever it does next will not be correct. At best it will just be a few lines of lost output, but it could be output at the wrong position on the screen, resulting in a garbled display. Or the size of your screen could be different, again garbling it.

Worse, the remote side could send an escape sequence that changes the terminal’s character set. If your local terminal misses that, then the incoming text will be unreadable. Of course, with the spread of Unicode this has become quite rare. You are most likely to see the problem with programs that switch character sets to draw a UI or other artwork; the line–drawing characters would be printed using ordinary letters and numbers.

What you really want to run is not tmux but a program called mosh. mosh is a drop–in replacement for ssh. It runs on both your local computer and on the remote computer, and synchronizes the state of your terminal for you. The remote end maintains a representation of the local state of the terminal, and visa versa. If you lose your connection, mosh only needs to copy the remote state to the local terminal to resume the session correctly. The other cool trick is that mosh uses a UDP connection instead of TCP. This combined with the encryption it uses allows it to seamlessly resume your session even if your IP address changes suddenly. It also keeps your session alive even if the UDP packets from your local machine stop arriving. If you suddenly close the lid of your laptop, suspending it, it will patiently wait for you to open the lid again and seamlessly reconnect.

[hnlmorg]

Mosh is a great tool but you’re thinking of tmux like a client side tool when in fact, like Mosh, you can run tmux server side and have it manage all of that annoying state you described earlier.

There’s definitely overlap in features between tmux and mosh but it’s better to think of them as solving different problems. Mosh is for working on laggy or unstable network connections. Whereas tmux is more like a terminal based tiling window manager.

At the end of the day there are as many good reasons to use tmux as there are good reasons not to. Like most things terminal based, it’s just a matter of personal preference

[db48x]

I didn’t say that it wasn’t. I was responding to the notion that “these features should be built into all conventional desktop terminal emulators.” There are reasons why it cannot just be built–in to the terminal emulator, and the best we can do currently is just to run some program like mosh or tmux on the remote side so that the terminal state is maintained correctly.

I suppose the terminal emulator could be more helpful though. For example, if you have a terminal emulator with local tabs/panes/splits/whatever, maybe it should orchestrate the process of connecting (or reconnecting) to the remote server. If I create a new tab or split the current window, it could connect automatically to the server for me. If it is connecting via mosh, then the terminal state in each of my tabs/windows/panes will be maintained correctly.