[cxr]

That should be table stakes at this point; these features should be built into all conventional desktop terminal emulators. I shouldn't have to run a second, inferior text mode terminal emulator inside the terminal emulator app that ships with my preferred desktop environment (and deal with the conflicts/impedance mismatch that falls out of this pairing).

Pretty nuts that so many desktops and independent modern terminal emulators lag so far behind GNU Screen, which was first released in 1987.

[baobun]

Hard disagree. I very much like my terminals thin and "stupid" (sixels, clickable links, speed, and workable CJK font/IME support are about the non-standard features I really want), leaving all the navigation to something like tmux/zellij/screen.

There are other features a desktop terminal emulator can not give you. And being able to maintain all the shortcuts and muscle memory across devices, servers, X11/Wayland, different DEs, and inside nested VNC or SSH sessions, more than compensates for "impedance mismatch" (curious what you're actually referring to here... Just putting a line in my shellrc to start a new tmux session unless the TMUX env var is already set makes it mostly seamless and you could do the same in terminal emulator conf if you dislike putting such things in your shell or profile).

Unix philosophy: I want my graphical terminal emulator to render my sessions on my display. The stuff happening inside should mostly not be its concern.

> I shouldn't have to

Good thing you don't have to, then. For casual users, emulators like Kitty, xfce-terminal and Konsole exist and are quite popular. Yeah, a batteries-included terminal emulator sounds more appropriate for you and probably the majority. For "niche" users like sysadmins and many power users, tmux is the table-stakes. There's no one-size-fits-all and not everything has to be for everyone.

> GNU Screen

Well, there's the topic of the thread...

[kps]

As for me, I like the “do one thing well” philosophy — I don't want my terminal to manage multiple sub-‘windows’, because I already have a window manager that I like just fine thank you.

`tmux` is actually more than I want, because it interposes itself as a terminal emulator in its own right (hence, per the thread parent, requiring its own sixel support on top of the display terminal's) and use `dtach` instead: it's just a pass-through session holder. Something like `tmux` is necessary when you want to connect to a session from significantly different terminals (say, iTerm on a Mac and Konsole on *nix) but I don't do that.

[michaelmior]

Personally I'd much rather run that server-side. I use iTerm which has a lot of great features for session management, but I like being able to connect from any machine and keep the exact state I was in rather than having it tied to my local client.

[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.

[foresto]

> these features should be built into all conventional desktop terminal emulators.

Lennart, is that you? ;)

[freedomben]

I prefer tmux because I can run it on servers/remote machines too. It doesn't require X so runs perfectly and happily on headless machines. Can also be nested.

I'm all for adding those features to the terminal emulators, but it will never meet and certainly not exceed tmux in flexibility, power, portability, and compatiblity.