Live data from Hacker News

St – simple terminal

st.suckless.org

31–40 of 88 posts

Re: St – simple terminal

#31

I like suckless. I use some of their tools within my Awesome(WM) sessions. However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better". FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fo…

I use the Xfce 4 Terminal on a i3 with no DE. Works wonderfully and has all the features I care for and need.

Re: St – simple terminal

#32
post #18

suckless sounds quite like a good name. I'm currently also working on some terminal style I/O and I can totally understand why there are programs with >30k lines of code just for being a terminal emulator. terminal communication is not really standardized. It has grown since a time where "computer" meant a person who calculates things. So I'm not sure it St could arrive at a stable state without also having a few tho…

> But what is wrong with Gnome-Terminal?

The dependencies: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/g...

If you're using Gnome, you probably have those already so it's no big deal. The same goes for Konsole in KDE: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/k...

If not, pulling in a few hundred MB of dependencies for a terminal emulator seems distasteful. st is much more self-contained: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

That's why st is usually compared to xterm; they're small, basic and desktop-agnostic.

Re: St – simple terminal

#33
post #30
post #29

> xterm is bloated and unmaintainable (...) It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The way these things are usually implemented is that there is an interface of a "terminal" and implementations. As long as implementations do not break the abstraction and do not require modifications in the interface and other parts of code these implementations do not decrease i…

> Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. I think as long as there is someone to maintain that driver, it doesn't get removed.

But if removing them would simplify other parts of code, I think they would do it, like they did for i386 recently.

Re: St – simple terminal

#35

I like suckless. I use some of their tools within my Awesome(WM) sessions. However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better". FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fo…

st is not about rewriting xterm.

it's about removing features, and then rewriting.

for example, it doesn't even have scroll back! ... which is the reason i don't care much for it.

Re: St – simple terminal

#36

I like suckless. I use some of their tools within my Awesome(WM) sessions. However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better". FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fo…

I've used gnome-terminal, sakura and now I'm using terminator: http://gnometerminator.blogspot.co.uk/p/introduction.html The main difference with the other terminal emulators is that I can easily do horizontal and vertical window splits. Many use screen or tmux for that but I find them too limiting, especially in their scrollback implementation.

i always found screen splitting in the terminal when you have a graphical window manager kinda of silly.

Re: St – simple terminal

#37
post #9

Earlier quoted context omitted.

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?

Re: St – simple terminal

#38
post #7

> 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..…

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

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!
Post reply on HN