tmux VS Mosh

tmux is a powerful terminal multiplexer that enhances productivity by allowing session persistence, window and pane management, and customization through key bindings and configuration files. It supports scripting for automation, facilitates collaboration with shared sessions, and integrates well with various shells and tools.

Tmux

Configure the frontend Open up a new terminal. P.S. We can split the terminal session using tmux or run it as a system service, but to keep things fairly simple, we would leave the backend running in one terminal and open another terminal for the frontend.

I have been using tmux for a while now. It was really worth it, especially after I started using neovim. One thing was really missing though compared to my previous setup and that was opening URLs. I always used my mouse to do that, but now I couldn't even do that because I am using the good old xterm as a terminal which doesn't have a built in feature like that.

If the cursor is located on a number, the shortcuts +a and +x increments/decrements that number. Not only do I not have any use for this behaviour, +a is also used to control tmux, which I normally use together with neovim.

I said multiplexer didn't I? tmux to be exact. Another game-changer for me. The beauty of using tmux is that I can create sessions, panes, and windows that can then be moved, split, detached, and everything in between. I also have Neovim shortcuts built in so that I can easily move with hjkl which if you know Neovim, that's life.

> tmux/screen do not break copy-paste

Tmux breaks interacting with the clipboard so much that it has its own dedicated Wiki page dealing with all of the different issues and settings: https://github.com/tmux/tmux/wiki/Clipboard

If so, tmux in control mode [1] plus iTerm2 could be what you're looking for. You would use the -CC flag when starting tmux either locally or on a remote host.

This brings all the niceties of an iTerm shell session, but still allow you to detach from tmux and reattach at a later point whilst still using the native iTerm features. Almost indefinite scrollback, as you mentioned. Also good terminal search facilities, and features to filter text in the session to display only lines that contain a keyword. Instant Replay lets you drag a slider and replay old TUI output that may have been erased from the screen [2]. And the configurable hotkeys are very convenient for pane splitting, which I find to be more convenient than the leader-plus-command of tmux. I find the toolbelt window useful, and sometimes define snippets of long cumbersome commands where it isn't possible or maybe appropriate to define aliases on a remote host. For local tmux sessions, I like some of the features of the iTerm shell extensions, like jumping back to the points of previous commands entered, which helps navigate through large amounts of console output. Or the directory name picker based on frecency, which is useful for adding directory names when composing long commands or to jump to a directory when using Zsh (which lets you omit the 'cd' command).

[1] https://github.com/tmux/tmux/wiki/Control-Mode

[2] https://iterm2.com/features.html

You can follow this guide to install Tmux on your system: Tmux Installation Guide

"Nvim 0.10 can now use the OSC 52 escape sequence to write to (or read from) the system clipboard."

This is a big deal! (it shouldn't be, but it is)

My main complaints about vim/emacs in the past was at the sheer complexity of getting something that should not even be a concern (clipboard integration) working properly, when other text/code editors did not have this problem at all.

Searching online, it seems like tmux has some nice documentation related to OSC 52 usage:

https://github.com/tmux/tmux/wiki/Clipboard

I will be playing around with this for a bit to understand it more. But honestly, this is the sort of thing that should "Just Work TM".

"VTE terminals (GNOME terminal, XFCE terminal, Terminator) do not support the OSC 52 escape sequence."

https://gitlab.gnome.org/GNOME/vte/-/issues/2495

That's a shame, but I'm not against using a different terminal emulator. Up until now I did not really have a good reason to.

Normal ssh is TCP-based. But there is also a different implementation named mosh.

Do you know mobile shell (mosh)? [1]

Seems like most of the features you need are what mosh offers. I've been using it for decades, probably, and it is pretty awesome for latent mobile connections (read as: throttled 2G @16kBit/s).

https://github.com/mobile-shell/mosh

I use tmux, but as far as unreliable connections, I've found mosh[0] to be the best solution to the problem (when you have the ability to install it). It basically runs a background process on connection not tied to the session that your client will automatically reconnect to if the connection fails. I regularly close my laptop, travel between home and work, open it back up and the connection is available almost instantly.

[0] https://mosh.org/

If you haven’t already, and I know this doesn’t hold up for GUI emacs or vim, but consider running them through https://mosh.org/

FWIW, I wouldn't try to parse escape sequences "directly" from the input bytestream -- it's easy to end up with annoying bugs. Longer-term it's probably better to separate the logic e.g.:

- First step (for a UTF-8-input terminal emulator) means "lexing" the input bytestream as UTF-8 into a stream of USVs, which involves some subtleties (https://github.com/mobile-shell/mosh/blob/master/src/termina...).

- Second step is to run the DEC parser/FSM logic on the sequence of USVs, which is independent of the escape sequences (https://vt100.net/emu/dec_ansi_parser ; https://github.com/mobile-shell/mosh/blob/master/src/termina...).

- And then the third step is for the terminal to execute the "dispatch"/"execute"/etc. actions coming from the FSM, which is where the escape sequences and control chars get implemented (https://github.com/mobile-shell/mosh/blob/master/src/termina...).

Without this separation, it's easier to end up with bugs where, e.g., a UTF-8 sequence or an ANSI escape sequence is treated differently when it's split between multiple read() calls vs. all in one call.

Btw, you can use mosh to hide the latency of SSH. https://mosh.org/

I've been using Kitty's SSH features for as long as I can remember but I recently setup Mosh and I really like how it doesn't drop connections and supports roaming.

I am surprised many people write about ssh into a server. Mosh[1] feels more responsive and it also supports longer sessions.

[1] - https://mosh.org/