I think the point is: do one thing and do it well.
In this view, I guess it's not the terminal's duty to do multiplexing, scrolling etc. Tmux is meant to do the job, so its codebase size should not be added together with st's. They're separate software, each doing its thing and doing it well, an approach completely opposite to that of other software (e.g. emacs) that do lots of things.
I'm not sure in what meaningful sense of the word tmux isn't also a terminal emulator, thus doing more than it should, if I follow your reasoning all right.
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.
That is true. It seems somewhat beside your original point, though, unless you are arguing that that difference cuts it clear which terminal emulator should handle scrollback
No, my point wasn't strictly about scrolling. My line of reasoning is:
1 tmux is needed to handle multiplexing
2 tmux also handles scrolling
3 if you need tmux for other things already, you don't need scrolling in the terminal emulator
I wouldn't say that, by this reasoning, it is the right place to implement scrolling, just that, since it's a solved problem, re-implementing it would be a useless duplication of effort.
But in this specific case I'd concede that the way tmux scrolls is not at all comparable with how a X terminal emulator would be expected to scroll.
In this view, I guess it's not the terminal's duty to do multiplexing, scrolling etc. Tmux is meant to do the job, so its codebase size should not be added together with st's. They're separate software, each doing its thing and doing it well, an approach completely opposite to that of other software (e.g. emacs) that do lots of things.