4 ms·

suckless is awesome! xmonad would totally suck without dmenu, i found zathura because of their "rocks" page, and st[+] has unicode support now, apparently?! mi

by auvrw 11y ago

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/ http://st.suckless.org/

deleted 11y ago
[deleted]
cm3 11y ago
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 :).
- sevensor 11y ago
  > you can build more prompts in Haskell Trying to customize xmonad is why I use i3 now.
- icebraining 11y ago
  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).
  - cm3 11y ago
    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.
- auvrw 11y ago
  > xmonad has a built-in (xmonad-contrib) program launcher prompt kinda-sorta... http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-AppLauncher.html 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 http://lpaste.net/145311 , except the completions list and tab stuff don't work aaand, i have to get back to "web" technologies :)
  - cm3 11y ago
    This is your easy Mod-p replacement: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-Shell.html 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.html#t:XPConfig http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt.h...
    - Arguggi 11y ago
      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=393&aid=3930005000&name=shell-compl_predicate.patch&token=ABZ6GAfgBm0bpLu0E74YtfArOYfYc2QLdQ%3A1447596010634 https://code.google.com/p/xmonad/issues/attachmentText?id=39... [2]: https://code.google.com/p/xmonad/issues/detail?id=393 https://code.google.com/p/xmonad/issues/detail?id=393
      - cm3 11y ago
        Care to resubmit that patch at https://github.com/xmonad/xmonad-contrib https://github.com/xmonad/xmonad-contrib? That way it can be part of the 0.12 release.
- esjeon 11y ago
  > 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.
  - cm3 11y ago
    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.
bluecalm 11y ago
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.
scriptdevil 11y ago
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
- cm3 11y ago
  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.
- ymse 11y ago
  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.
betaby 11y ago
'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.
- sevensor 11y ago
  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.

by auvrw 11y ago

deleted 11y ago

[deleted]

cm3 11y ago

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

sevensor 11y ago
> you can build more prompts in Haskell Trying to customize xmonad is why I use i3 now.
icebraining 11y ago
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).
- cm3 11y ago
  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.
auvrw 11y ago
> xmonad has a built-in (xmonad-contrib) program launcher prompt kinda-sorta... http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-AppLauncher.html 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 http://lpaste.net/145311 , except the completions list and tab stuff don't work aaand, i have to get back to "web" technologies :)
- cm3 11y ago
  This is your easy Mod-p replacement: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt-Shell.html 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.html#t:XPConfig http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt.h...
  - Arguggi 11y ago
    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=393&aid=3930005000&name=shell-compl_predicate.patch&token=ABZ6GAfgBm0bpLu0E74YtfArOYfYc2QLdQ%3A1447596010634 https://code.google.com/p/xmonad/issues/attachmentText?id=39... [2]: https://code.google.com/p/xmonad/issues/detail?id=393 https://code.google.com/p/xmonad/issues/detail?id=393
    - cm3 11y ago
      Care to resubmit that patch at https://github.com/xmonad/xmonad-contrib https://github.com/xmonad/xmonad-contrib? That way it can be part of the 0.12 release.
esjeon 11y ago
> 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.
- cm3 11y ago
  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.

bluecalm 11y ago

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.

scriptdevil 11y ago

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

cm3 11y ago
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.
ymse 11y ago
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.

betaby 11y ago

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

sevensor 11y ago
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.