Show HN: Terminal Multiplexer Inspired by I3

Hi again :).

I agree that non-i3 users need it the most, but have one use case in mind where you might want to combine i3wm + 3mux: remote work. If you ssh into a remote computer, you can not easily spawn new remote terminals. Having one terminal that runs ssh + 3mux lets you use i3wm-like keybindings inside the terminal to open remote splits and tabs with similar keybindings as you would locally. In particular, setting the i3wm $mod to super would make super+enter, super+hjkl, etc. act on local windows, while alt+enter, alt+hjkl, etc. act on remote windows. In a sense, ssh + 3mux would act as a "i3wm-style remote desktop".

If I understand correctly, 3mux does not have session management, but combining 3mux with abduco or dtach should solve that. (And arguably be a more Unix-philosphy solution.)

I think the best way to combine i3wm and 3mux would however be to change the i3wm $mod to win/super, instead of trying to use different modifiers in 3mux. As far as I know, no common terminals support other modifiers than ctrl and alt, and ctrl would collide with most terminal programs. (In tilish, I ended up offering a prefix key as an alternative to alt for people using Kakoune or Emacs.)

See https://unix.stackexchange.com/a/579359/5132 for the most common architecture. It's roughly the architecture of tmux and screen. It's roughly the architecture of http://jdebp.uk./FGA/bernstein-on-ttys/sess.html , too.

I have a somewhat different, layered, architecture with finer grained components. The terminal emulators, multiplexor, input method handler, and realizers are all separate processes, and the communication among them is via (memory-mapped) regular files and FIFOs.

* http://jdebp.uk./Softwares/nosh/guide/user-virtual-terminals...

It's more rigid in the multiplexing layer, with little notion of creating and destroying inner terminals on the fly and no notion of windows or panes, because it was initially created to be a user-space workalike for the kernel virtual terminals in Linux and FreeBSD, that are derived from SCO Multiscreen. So there's just the notion of a fixed set of virtual terminals, presented one at a time, with the Alt+function-key switching and a replacement chvt command.

It's more flexible in other ways, though. The components of the system are replaceable, and don't have to be put together in this particular way. There's no reason that one couldn't write another type of emulator, handling a completely different suite of escape and control sequences, and just plug it in alongside the existing one. And there's similar flexibility in the other layers: one can (and I do) simultaneously realize the same set of multiplexed terminals onto a remote terminal over an SSH connection as well as directly onto the local machine's framebuffer and keyboard(s). It could be realized onto X11, or (if someone finally documents the undocumented Mosh protocol) a Mosh client.

Indeed, there's no reason that a more complex multiplexing layer couldn't be substituted, providing something more like the screen/tmux paradigm, with the multiplexor starting up subordinate shell and terminal-emulator processes on the fly and compositing the lower screen buffers. But I didn't set out to reinvent screen/tmux. I set out to do virtual terminals in user-space instead of the kernel, with application mode code almost none of which (apart from the stuff that grants access to the framebuffer and keyboard devices) needs or runs with superuser privileges, and where the components are isolated even from one another.

See the StackExchange answer that I hyperlinked to for more on the actual terminal emulation part.