[krat0sprakhar]

Looks awesome, thanks for sharing! I've been using Byoyu[0] which has a similar goal, but I'm keen on trying out. Even though I've been a long-time tmux user, as a developer I don't even know where I would start if I wanted to build my own terminal multiplexer. Can you share some resources etc on what could a good starting point if I want to explore this as a side-project?

[0] https://www.byobu.org/

[aaronjanse]

My understanding is that a terminal multiplexer consists of three parts: 1. Managing shells and windows 2. Parsing the ECMA-35/ECMA-48 escape/control sequences 3. Rendering the shells' parsed output within their window boundaries

> Can you share some resources etc on what could a good starting point if I want to explore this as a side-project?

I'm still looking for resources myself. Check out JdeBP's comment for some good information https://news.ycombinator.com/item?id=22847168

[JdeBP]

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.