I spent a few days playing with st (st terminal | suckless terminal | simple terminal) after hoping to refresh my workflow a bit for 2019.
My current terminal is urxvt (rxvt-unicode) and the software itself hasn't been updated for nearly three years. The project seems to be near the end its lifecycle; its maintainer has clearly lost interest and hasn't built a community that wants to pick up the momentum. I'd be glad to do so, but don't have the luxury of tonnes of free time at the moment.
So I downloaded
st and was initially impressed by the claims made for "simplicity". The codebase looks clean by comparison to urxvt and its apparent minimalism was appealing.
Then I tried to actually use it. Here are my observations.
urxvt daemon is faster by design
strests quite heavily on its claim to being very lean and low on resources. In actuality, if you run a system with many terminals open,
urxvthas a daemon functionality that makes it more efficient than any non-daemon approach could be, simply by design.
(Lack of) .Xresources support in st terminal
ststarted out without support for .Xresources, and still doesn't support it by default. You have to patch it in. Even with the patch
ststill doesn't support basic functionality. In my case, letter spacing is not supported, and it's not a top priority over my other work such that I'd bother wasting time writing a new patch myself. Urxvt already has native .Xresources support, so that's a reason to stay with
Font rendering is subpar in st terminal
- font rendering seems to works better using
st, but again, has limited functionality. I can foresee other basic missing features and time wasted getting simple things to work due to the
stphilosophy of "simplicity", i.e. missing features that
urxvthas already implemented.
Tabs are completely unsupported in st terminal
- tabs are another feature that's missing in
st. Again, there's a patch (correction:
stdoesn't support tabs at all; you have to use another suckless program called
tabbed), but it's poorly implemented. In my case, you can use tabs, but there's no straightforward way to name them. Tab-naming depends on your shell, and some shells (zsh) are easier for this than others (fish).
After clearing that hurdle, it became clear that the tabs are not capable of using .Xresources to set their font. So you'll have tabs using one font that can only be set by altering the source code and re-compiling, versus terminals that can be set using .Xresources. As before,
urxvt implements this functionality properly by drawing all of its font rendering data from .Xresources.
- I hoped that tab rendering would be faster using
st, but it's not: similar to
urxvt, you have to guess and tweak the tab-loading time using
sleepcommands. So that's not an improvement; might as well stay with
urxvtif tabs are your jam.
Also regarding tabs, I've heard people claim that
st relies heavily on
tmux for its functionality. "You're probably using tmux anyway, so who cares", is the typical idea. Well, no, I don't inevitably use
tmux for every terminal, and it's a waste of resources to load it every time I want tabs (or scrollback ability). Plus, I've found that
tmux doesn't always play nice with keyboard shortcuts and it's overall just another hassle when all you need is the basics (tabs, scrollback, etc.) that could easily be built into the terminal itself.
at least on Reddit, I've found the
stcommunity to be strangely insular and unwelcoming. Apparently they're proud of being exclusionary and "the Amish of software design". I'm not particularly concerned -- dealing with the
urxvtcommunity was less than fun at times -- but
stis stunting its own growth as a piece of software by snubbing new people instead of welcoming them. That means few people use it, and few people will contribute to it. So it remains trapped in a low-value cycle where
stlacks basic functionality, practically no one uses it and practically no one cares to adopt or improve it. That's how projects lose momentum and die.
urxvtalready seems mostly dormant, but it's based on rxvt and extends its predecessor significantly.
urxvt, then, is a strong, robust piece of software that can fulfill most users' needs. Instead of requiring patches to do practically anything useful,
urxvtallows for Perl extensions (tab support, for example, arrives through a Perl extension). One of my peeves about
urxvtis that support for newer languages like Python and/or Ruby would be more modern, since people rarely write anything significant in Perl anymore. But it's still better than having to throw your brain at patching the source code in C any time you want to add new functionality. And as mentioned, performance isn't an advantage for
urxvtif you're using the
Overall, there's really no benefit to using
st rather than a rock-solid, well-established terminal emulator like
urxvt (urxvt-unicode). You can trust
urxvt, even with the daemon. It simply doesn't crash, ever, and the resource usage is very low (although it does accumulate over time, so you may need to re-boot occasionally, depending on how much memory you have).
mlterm-- probably the best "second choice" alternative to
urxvt, if only because it's mostly the same as
urxvtand is still in active development/maintenance.
kitty-- amusingly, there's another terminal named "kitty", but its founder gave the middle finger to jerks on Reddit for harassing him about the name. :) Kitty looks great, but it's quite new and has issues with dependencies (harfbuzz, specifically) that I've seen in other software. If you can make it work for you, great. Hopefully, as the software matures, it will become a great option that's at least as fast as
[link] [comments] ...