5 ms·

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 th

by klez 12y ago

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.

boomlinde 12y ago
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.
- klez 12y ago
  Fair enough, in a way, but I'd say you can't launch it stand-alone inside an X session without using another terminal emulator (st, xtrem, whatever).
  - boomlinde 12y ago
    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
    - klez 12y ago
      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.
- chriswarbo 12y ago
  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?
  - boomlinde 12y ago
    > 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"?
    - chriswarbo 12y ago
      > 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.

by klez 12y ago

boomlinde 12y ago

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.

klez 12y ago
Fair enough, in a way, but I'd say you can't launch it stand-alone inside an X session without using another terminal emulator (st, xtrem, whatever).
- boomlinde 12y ago
  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
  - klez 12y ago
    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.
chriswarbo 12y ago
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?
- boomlinde 12y ago
  > 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"?
  - chriswarbo 12y ago
    > 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.