Live data from Hacker News

St – simple terminal

st.suckless.org

41–50 of 88 posts

Re: St – simple terminal

#41
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…

Interesting, as I too compared scrolling performance, and it was 6x slower than both st and urxvt (as did others in ##c). I suggest trying it again.

But I also don't care about font rending, and having my code compile 6x slower is a non-starter, so take from that what you will.

Re: St – simple terminal

#42

Earlier quoted context omitted.

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!

nix really does make people optimistic

Re: St – simple terminal

#43
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.

You should be using abduco instead of dtach now http://www.brain-dump.org/projects/abduco

Re: St – simple terminal

#44
I feel stupid. I opened up the comments and then thought to myself "Hey, I remember reading a confession from the xterm developers themselves about how terribly bloated xterm is, I should go and find it again". After 5 minutes of searching I finally found it... Only it was on the suckless page for st.

Re: St – simple terminal

#45
post #12

Earlier quoted context omitted.

I've been using a few - in the end I landed on sakura: http://www.pleyades.net/david/projects/sakura I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like confi…

Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm. I do have one question though, why are the colors more pale in sakura than in xterm? And is there any way to change it?

I have no idea about sakura, but being a libvte-based terminal, I highly doubt it's comparable (or even approaches) xterm in term of rendering speed.

I'm wondering how people can compare these terminals mentioning speed, considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring?

xterm is quite fast (in the order of 3-5x faster) than any libvte-based terminal. Try doing something like "time [term] -c 'cat '", and try varying the scrollback size to have a real measure.

[u]rxvt in turn is even faster, especially with large scrollback buffers, which is the main (I could say only, really) reason I use it. As in, 10x faster than any libvte based terminal.

I also use suckless tools (with spectrwm), though I never had a reason to investigate st. urxvt supports fallback fonts, which for UTF-8 text is essential.

Re: St – simple terminal

#46
post #36

Earlier quoted context omitted.

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.

It means you can do screen splitting on a remote machine and still have the same workflow as your local sessions, which is pretty nice.

Re: St – simple terminal

#47
post #36

Earlier quoted context omitted.

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.

I'd love it if there would be graphical frontend to tmux or screen. Something that would look very much like a terminal emulator, with tabs and splits, but backed by screen or tmux, whereby each tab or split window would be a tmux or screen window. And the awesome part is that when you're elsewhere, you could ssh in and attach to that tmux or screen session.

Re: St – simple terminal

#48
post #36

Earlier quoted context omitted.

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.

This is especially true when using a tiling window manager such as wmii.

In that case you don't even have to rearrange windows - each new window automatically takes part in the split. And you can combine terminal sessions, browser, etc. as you wish. I find this a lot easier to use than screen/tmux.

Re: St – simple terminal

#49

> Some random program complains that st is unknown/not recognised/unsupported/whatever! I really wish there was a better way to deal with this (I have the same problem with rxvt-unicode-256color). I'm obviously not going to make install a graphical terminal emulator on some random server I'm logging into.

I'd argue that they should go the route that most terminal programs do and just announce they're xterm, or at least have a config file option for doing so.

Re: St – simple terminal

#50

Earlier quoted context omitted.

Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm. I do have one question though, why are the colors more pale in sakura than in xterm? And is there any way to change it?

I have no idea about sakura, but being a libvte-based terminal, I highly doubt it's comparable (or even approaches ) xterm in term of rendering speed. I'm wondering how people can compare these terminals mentioning speed , considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring? xterm is quite fast (in the order of 3-5x fast…

> I'm wondering how people can compare these terminals mentioning speed, considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring?

Not sure about others, but the first thing I test: dmesg; ps auxww; ls /dev

I only really care about apparent speed and, like I said, sakura was the only one that was comparable to xterm.

None of the other terminals I have tried (and only now I realize that they have libvte in common, thanks for that) have managed to perform acceptably (for me, at least).

Post reply on HN