Hacker News Reader

Comment by auvrw | Hacker News Reader

suckless is awesome! xmonad would totally suck without dmenu, i found zathura because of their "rocks" page, and st[+] has unicode support now, apparently?! might be time to switch from urxvt...

i'm not saying "suckless all the things!" these people have made my daily life easier, though.

[+] http://st.suckless.org/

View on HN

I did a small experiment to see if st would actually be much snappier. Font rendering was a little worse but that was tolerable.

ST is fast (as expected)

  $ time $(for i in `seq  1 100`; do st -e true &> /dev/null ; done)
  real	0m5.493s
  user	0m4.417s
  sys	0m0.647s

URxvt is a little slower (but traditional wisdom should tell you that if it is actually so small that you need to measure it to perceive the difference, the difference probably doesn't matter)

  $ time $(for i in `seq  1 100`; do urxvt -e true &> /dev/null ; done)
  real	0m11.099s
  user	0m9.780s
  sys	0m0.853s

URxvt client (with a separately launched urxvtd) is faster than st.

  $ time $(for i in `seq  1 100`; do urxvtc -e true &> /dev/null ; done)
  real	0m4.593s
  user	0m0.007s
  sys	0m0.017s

Given how solid urxvt has been for me over the years, and given that I run urxvtc already, I don't see why switching to st would help (the argument against featuritis can obviously be made, but urxvt is fairly minimal as well).

Note: I do not know how it would affect it, but I also have a .Xdefaults that sets fonts, colors etc for URxvt.

Edit:

adding xterm to the comparison since some sibling comment mentioned it

  $ time $(for i in `seq  1 100`; do xterm -e true &> /dev/null ; done)
  real	0m8.525s
  user	0m2.777s
  sys	0m0.770s

I wasn't talking about startup speed as that can be ignored given the kind of shells and configs we use these days which will consume most of the start time.

What I was talking about were things like how much memory overhead the emulator has and how fast it paints stuff or how quickly it responds. Some things were slower in urxvt and then some things didn't work as correctly as in xterm, so I didn't bother configuring urxvt for more speed. st, on the other hand, wasn't faster and actually was heavier memory-wise when I tried it the last time.

I ran some benchmarks with perf stat a while back, consisting of displaying a multi-MB text file on screen. st was a lot slower than urxvt, but on par with VTE based terminals. urxvt has other problems though, so I'll stick with st.

xmonad has a built-in (xmonad-contrib) program launcher prompt that doesn't require an extra program and is more comfortable to use. There are other prompts included as well and you can build more prompts in Haskell. st used more memory and was slower than xterm last time I tried. I try using urxvt or st and only xterm works without problems or slowdowns. We may be using it in different ways and exercise different features of the terminal emulators :).

urxvt with the daemon (urxvtd & urxvtc) is blazing fast, in my experience. That said, it's not fun when all my terminals suddenly freeze (happens to me once a year, roughly).

It's faster to start for sure. I don't doubt that it's faster for you, since many users praise urxvt's speed over xterm. It just hasn't been the case for me.

> xmonad has a built-in (xmonad-contrib) program launcher prompt

kinda-sorta...

http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-A...

doesn't do exactly what i want... i'm looking for something more like this

http://lpaste.net/145311

, except the completions list and tab stuff don't work

aaand, i have to get back to "web" technologies :)

This is your easy Mod-p replacement: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-S...

You can give it something else than defaultXPConfig to customize the look and completion behavior: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt.h...

I just switched from dmenu to the contrib prompt, only thing to look out for is that the searchPredicate function of the XPConfig doesn't actually seem to do anything.

Setting:

  searchPredicate :: String -> String -> Bool
  searchPredicate = \_ _ -> False

seems to make no difference.

And the default is:

  searchPredicate = isPrefixOf

Patching and recompiling with this patch[1] mentioned here[2] seems to fix the issue.

[1]: https://code.google.com/p/xmonad/issues/attachmentText?id=39... [2]: https://code.google.com/p/xmonad/issues/detail?id=393

Care to resubmit that patch at https://github.com/xmonad/xmonad-contrib? That way it can be part of the 0.12 release.

> st used more memory and was slower than xterm

Since st has no scroll buffer, theoretically it's impossible for st to consume more memory than xterm. If st does eat up more, it should be because of its screen buffer, whose size is decided by the size of its window.

Also, yes, the rendering portion of st is not the fastest. I know it pretty well because I implemented it like an year ago. It has been improved, but it's still kinda hacky due to lack of proper Unicode layout engine (or normalization). And what makes things worse is that existing layout engines(ICU, harfbuzz, etc) are just "sucks" for suckles community, while making a new one is not feasible AFAIK.

I don't understand what you're saying about the three different buffers and if you mean that there's a hidden buffer I don't see in xterm but which is used somewhere else in the stack.

I exclusively use bitmap fonts in terminals and editors for crisp and clear text and cannot get bitmap fonts to work in st config.h anymore.

> you can build more prompts in Haskell

Trying to customize xmonad is why I use i3 now.

I've learnt basics of Linux with dwm + dmenu. It's awesome. I long for the day dwm style Windows management is smooth on Windows. It's possible to create many virtual desktops in Windows 10 but windows snapping thing isn't close to the functionality of dwm imo.

'st' falls short in very basic real life [for me] test - paste-ing 2-5MB of the text via ssh to the remote router(yes I'm more than aware about about other methods, those are emergency cases when I have to connect via someone's laptop with data modem). 'st' just freezes, I've reported that at the IRC channel, got some debugging tips, problem confirmed but as I see in git hasn't been fixed. Need to say `st` is not alone with that problem - gnome terminal has it, perhaps overs. Old school xterm and surprisingly 'konsole' pass that test.

I wanted to like st, but vim was kind of broken in it. I'm sure the suckless guys would tell me vim sucks and I should use vi instead. I think it's great that we have people with hard-line, absolutist views about technology. I might not want to live in their world, but they're exploring possibilities the rest of us would never consider.

Reply on news.ycombinator.com