1. Betriebssysteme >
  2. Linux Tipps >
  3. After experimenting with st (st terminal | suckless terminal | simple terminal), here are several reasons to use urxvt -- or any comparable terminal emulator -- instead.


ArabicEnglishFrenchGermanGreekItalianJapaneseKoreanPersianPolishPortugueseRussianSpanishTurkishVietnamese
Anzeige

After experimenting with st (st terminal | suckless terminal | simple terminal), here are several reasons to use urxvt -- or any comparable terminal emulator -- instead.

Linux Tipps vom 12.01.2019 um 00:50 Uhr | Quelle reddit.com

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

  • st rests quite heavily on its claim to being very lean and low on resources. In actuality, if you run a system with many terminals open, urxvt has 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

  • st started out without support for .Xresources, and still doesn't support it by default. You have to patch it in. Even with the patch st still 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 urxvt.

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 st philosophy of "simplicity", i.e. missing features that urxvt has already implemented.

Tabs are completely unsupported in st terminal

  • tabs are another feature that's missing in st. Again, there's a patch (correction: st doesn'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 sleep commands. So that's not an improvement; might as well stay with urxvt if 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 st community 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 urxvt community was less than fun at times -- but st is 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 st lacks 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.

  • urxvt already 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, urxvt allows for Perl extensions (tab support, for example, arrives through a Perl extension). One of my peeves about urxvt is 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 st over urxvt if you're using the urxvt daemon.


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

Other alternatives:

  • mlterm -- probably the best "second choice" alternative to urxvt, if only because it's mostly the same as urxvt and 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 urxvt.

submitted by /u/mitrespear
[link] [comments] ...

Komplette Webseite öffnen

Newsbewertung

Kommentiere zu After experimenting with st (st terminal | suckless terminal | simple terminal), here are several reasons to use urxvt -- or any comparable terminal emulator -- instead.