Live data from Hacker News

St – A simple terminal implementation for X

st.suckless.org

191–200 of 223 posts

Re: St – A simple terminal implementation for X

#191
post #62

I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.

I think the suckless project has correctly identified that a lot of software sucks, but their attempts to make it "suck less" are focusing on the wrong points. A lot of mainstream software is grossly inefficient, bloated and resource-intensive, and that's not necessarily because they're featureful. It's certainly possible to write software that is both featureful and efficient, but suckless aggressively cuts features…

For better or worse, Suckless's problem isn't with code bloat so much as code complexity. More features mean more code to debug. Better algorithms can also mean more code to debug. If you constrain your design scope, you can write vastly simpler programs that are more stable and easier to comprehend.

It's the same rationale that leads one to use a pen and paper rather than a note taking app.

Re: St – A simple terminal implementation for X

#192
post #17

Earlier quoted context omitted.

I always find tmux's scrollback to be vastly inferior to a native terminal's though. There are several reasons, but the biggest is that I'm pretty sure it's not possible to get more than a screenfull of text to my local X11 PRIMARY selection.

I know that there is an option for integrating tmux's internal clipboard with X11's but I haven't bothered with them because I prefer to keep the clipboards of the various terminal apps I use separate.

It depends ultimately on the terminal to support it though. Only Linux terminals that support it atm are xterm and (u)rxvt, and there is an out-of-tree patch for st that I made (though it was rejected for being too long (around 40 lines).

Re: St – A simple terminal implementation for X

#193

Earlier quoted context omitted.

And then you have tabs that you can't copy from using your mouse because you wind up selecting content from multiple tabs.

when I use tmux for scrolling inside st i can select text only in the current window/pane I'm and copy that text only, without the mouse obviously

You can with the mouse as well. st doesn't support the OSC52 (Ms termcap) for setting the selection by this method, though I have an out-of-tree patch that does support it (also available as a branch in the Wayland port).

Re: St – A simple terminal implementation for X

#194
post #89
post #61

Earlier quoted context omitted.

Sadly Terminology doesn't have support for 24bit RGB sequences (true color): https://gist.github.com/XVilka/8346728

(main developer of Terminology here) As stated on https://phab.enlightenment.org/T746 , it is not an easy move due to the way the text grid is designed. I might work on it someday.

unrelated: are you the billiob that used to contribute to aMSN back in the days?

Re: St – A simple terminal implementation for X

#195
post #149

Earlier quoted context omitted.

this is not entirely true, xmonad's config file happens to be a haskell file, but I don't need to recompile the whole xmonad project if I want to change it, I just start xmonad again. It does some tricks to do this (mainly the _main_ xmonad executable compiles a custom binary for you taking the xmonad.hs as input), but it's a different case. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Conf...

If this experience has been improved, I might try xmonad again. I used it for 2.5 years but switched to i3 in 2013 after finding myself in cabal hell for the umpteenth time. Recompiling GHC to make my window manager work was not my idea of a good time.

I switched from xmonad to another window manager and eventually to i3 many years ago, and there's no way I'm going back.

Yes, you can do simple stuff in xmonad without knowing Haskell. But for more complicated stuff, you have to either copy and paste code that you don't understand, or ask someone who knows Haskell to write it for you. And there's no way you're going to be able to do troubleshoot non-obvious problems without either knowing Haskell or once again asking someone who knows Haskell to do it for you. That's way too much of a pain in the ass.

Configuring and troubleshooting i3 doesn't require knowing Haskell, is really simple, flexible enough for what I need, and any advanced functionality I want it to perform I can program in my own language of choice.

Re: St – A simple terminal implementation for X

#196

I like the principles behind its design, but not supporting scrollback and saying "that functionality should be provided by tmux or something similar" is baffling when it's done in the name of removing bloat and complexity. Not everybody wishes to use a terminal multiplexer in all cases, either.

What's the problem with typing tmux? I think this is exactly right for the typical audience of suckless projects. No dwm or dmenu users are complaining about "missing features".

Re: St – A simple terminal implementation for X

#197
post #124
post #99

Earlier quoted context omitted.

If it's one thing I've often had to change across systems (hardware and operating systems) it's things like font type and size. If one works mostly from one workstation (eg: a laptop) this is less of a hassle (just need to change on each new generation of ppi, and perhaps on some major system upgrades) -- but then one might want to switch things up as new fonts are released every so often. Edit-compile-run is a rathe…

For windows ten I'm using a combination of babun/WSL and cmder. But I agree that there is no good terminal emulator. It's not terribly surprising though. When those aren't enough I have a "seamless" ubuntu VM running.

I think it's somewhat surprising that they got the Linux subsystem for Linux working well, but apparently didn't spend much time on making a proper terminal experience.

Don't get me wrong powershell/the standard terminal is miles ahead of the old crappy cmd.com - but bundling a solid terminal would've gone a long way to pacify my desire to dual boot Linux (read:stop using w10) on my Surface pro.

If I weren't teaching students that run w10 on their own pcs, I would probably have relegated w10 to a vm/wine under Linux.

Re: St – A simple terminal implementation for X

#198

Earlier quoted context omitted.

> Their browser, surf, doesn't even support tabs as far as I can remember. There is a general tabbing frontend that allows you to tab all sorts of applications: http://tools.suckless.org/tabbed .

I've never used surf, but I really do like tabbed. It plays super nicely with most tiling window managers I've used, and lets me get the single best feature (ymmv) of i3 on xmonad.

Could you elaborate on how you use tabbed with i3, and how it's better than simply using i3's native tiling features?

Re: St – A simple terminal implementation for X

#199
post #197
post #124

Earlier quoted context omitted.

For windows ten I'm using a combination of babun/WSL and cmder. But I agree that there is no good terminal emulator. It's not terribly surprising though. When those aren't enough I have a "seamless" ubuntu VM running.

I think it's somewhat surprising that they got the Linux subsystem for Linux working well, but apparently didn't spend much time on making a proper terminal experience. Don't get me wrong powershell/the standard terminal is miles ahead of the old crappy cmd.com - but bundling a solid terminal would've gone a long way to pacify my desire to dual boot Linux (read:stop using w10) on my Surface pro. If I weren't teaching…

I use st in i3 under Cygwin on Windows 8.1. If Cygwin works in Windows 10, that (or any other Linux terminal manager of your choice) should be doable there too.

Re: St – A simple terminal implementation for X

#200
post #49

Earlier quoted context omitted.

Likely they enjoy tinkering with hardware, so they just needed the serial line support themselves.

With serial support, you definitely want scrollback, since you can't run GNU screen (or tmux for the hipsters) during a HW bootsequence. It absolutely seems like very conflicting decisions user-experience wise.

You can absolutely run GNU screen during a HW boot sequence through serial. See the Windows Types[1] section of the GNU screen manual.

[1] https://www.gnu.org/software/screen/manual/html_node/Window-...

Post reply on HN