4 ms·

> xterm is bloated and unmaintainable. [...] It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternat

by otikik 12y ago

> xterm is bloated and unmaintainable. [...] It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternative, rxvt has only 32K lines of code. This is just too much for something as simple as a terminal emulator; it’s yet another example of code complexity. Ok, I am interested. > How do I scroll back up? > - Using a terminal multiplexer [shows tmux example] Emm... tmux is a 32K lines of code. That kind of defeats the purpose of the opening paragraph.

agumonkey 12y ago
I heard dtach + dvtm were smaller, but I'm not sure.
- chriswarbo 12y ago
  Nice, not seen dvtm before. Since I've not seen it mentioned in other multiplexer comparisons I was assuming it's not in major repos yet, but an optimistic "nix-env -i dvtm" has installed it!
  - agumonkey 12y ago
    nix really does make people optimistic
- not_with_retard 12y ago
  You should be using abduco instead of dtach now http://www.brain-dump.org/projects/abduco http://www.brain-dump.org/projects/abduco
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?
unwind 12y ago
Not quite, the opening paragraph says rxvt is "only 32K", but of course st (which is the program being talked about) is around 4K. It's easy to count, since it's mostly a single file: http://git.suckless.org/st/tree/st.c http://git.suckless.org/st/tree/st.c. :)

by otikik 12y ago

agumonkey 12y ago

I heard dtach + dvtm were smaller, but I'm not sure.

chriswarbo 12y ago
Nice, not seen dvtm before. Since I've not seen it mentioned in other multiplexer comparisons I was assuming it's not in major repos yet, but an optimistic "nix-env -i dvtm" has installed it!
- agumonkey 12y ago
  nix really does make people optimistic
not_with_retard 12y ago
You should be using abduco instead of dtach now http://www.brain-dump.org/projects/abduco http://www.brain-dump.org/projects/abduco

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?

unwind 12y ago

Not quite, the opening paragraph says rxvt is "only 32K", but of course st (which is the program being talked about) is around 4K. It's easy to count, since it's mostly a single file: http://git.suckless.org/st/tree/st.c http://git.suckless.org/st/tree/st.c. :)