Terminal emulators accept drawing commands (literal and control characters) and render them to some kind of device (eg. a framebuffer, an X window, a Wayland surface, etc.).
Multiplexers accept drawing commands from multiple applications and combine them into one "root window".
By analogy, Linux launches a single process (init) which then handles all the others. The init system is not a kernel.
On the other hand, X11 doesn't just render a single root window (eg. controlled by the window manager). Instead it allows multiple clients to each draw to multiple windows, and the window manager performs a lot of back-and-forth communication with X to keep track of them.
In that sense X is certainly doing more than it should. Is tmux? Probably. Hell, it contains a mode-line with a clock! Why not use the existing multiplexing to offer a "sticky" single-line window, in which we can run some arbitrary status-displaying program?
> Terminal emulators accept drawing commands (literal and control characters) and render them to some kind of device (eg. a framebuffer, an X window, a Wayland surface, etc.).
Multiplexers accept drawing commands from multiple applications and combine them into one "root window".
If we accept for the sake of discussion that rendering to a "device" is the distinguishing characteristic of terminal emulators here, rather than, say, emulating terminals (which tmux certainly does), can't you think of another terminal emulator as such a device?
I can't really tell how the Linux init analogy is valid and what your point of making it is. Is the init system a "kernel emulator" or a "kernel multiplexer"?
> If we accept for the sake of discussion that rendering to a "device" is the distinguishing characteristic of terminal emulators here, rather than, say, emulating terminals (which tmux certainly does), can't you think of another terminal emulator as such a device?
It depends whether you think "Save to PDF" printer drivers really are printing. Does tmux "certainly" emulate a terminal, given that I can't observe any of the output or send it any input without assistance from another terminal emulator, like st?
> I can't really tell how the Linux init analogy is valid and what your point of making it is. Is the init system a "kernel emulator" or a "kernel multiplexer"?
The init system is like a "process multiplexer". The kernel only starts one process; if we tell it to start bash, we have a shell but not much else (until we fork stuff off manually). If we tell it to start an init system/daemon then we get a whole bunch of processes started for us during boot.
Likewise, when we start a terminal emulator we can run bash to get a single shell session, or we can run a multiplexer to get many.
> It depends whether you think "Save to PDF" printer drivers really are printing.
How does it depend on that? When you express an argument as an analogy without further explanation you lose a lot of information.
> Does tmux "certainly" emulate a terminal, given that I can't observe any of the output or send it any input without assistance from another terminal emulator, like st?
It "certainly" emulates terminals in that it behaves like one to the user and to programs that use it as a terminal, just like xterm or st. Whether the platform it uses for presenting this to the user is X11 or a terminal/another terminal emulator seems irrelevant to me.
> The init system is like a "process multiplexer".
It isn't a process multiplexer. How is it "like" a process multiplexer? init maybe starts a bunch of processes, but it doesn't do any multiplexing or even manage their communication at all.
> Likewise, when we start a terminal emulator we can run bash to get a single shell session, or we can run a multiplexer to get many.
You don't need to use a terminal multiplexer to have multiple shell sessions.
Multiplexers accept drawing commands from multiple applications and combine them into one "root window".
By analogy, Linux launches a single process (init) which then handles all the others. The init system is not a kernel.
On the other hand, X11 doesn't just render a single root window (eg. controlled by the window manager). Instead it allows multiple clients to each draw to multiple windows, and the window manager performs a lot of back-and-forth communication with X to keep track of them.
In that sense X is certainly doing more than it should. Is tmux? Probably. Hell, it contains a mode-line with a clock! Why not use the existing multiplexing to offer a "sticky" single-line window, in which we can run some arbitrary status-displaying program?