Live data from Hacker News

St – A simple terminal implementation for X

st.suckless.org

121–130 of 223 posts

Re: St – A simple terminal implementation for X

#121
post #86

Earlier quoted context omitted.

This. Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software. In fact, for the very same st, to change font, colour scheme, or hotkeys/shortcuts - one has to edit config.h file and recompile. There is no traditional text config file or "Preferences" menu. This might sound bizarre at first, but actually works as well as editing a text config file: config.h is…

It is still bizarre because not every user wants to and/or doesn't have the skills to do that.

The Xmonad window manager is configured by editing its source code as well, and believe me, you don't have to know Haskell to do it. They pushed the DSL approach to a point where the main function reads like a configuration file, whose format can be learned just by looking at it.

Re: St – A simple terminal implementation for X

#122

Earlier quoted context omitted.

Yes, and that's perfectly ok. These people simply aren't the target audience, just like you wouldn't recommend Arch to a Linux beginner.

Not having the skills isn't the thing that should stop someone in either scenario, it's not wanting the skills. Arch is great for a beginner that wants to know how to set up their own bootloader and similar things, you can use Ubuntu for years without gaining that knowledge. Or how much C editing and compiling does the average Unix user happen to run into? There's very little natural progression in computer use, peop…

if you don't like it than fork it

Re: St – A simple terminal implementation for X

#123

Earlier quoted context omitted.

What reasons are there not to use tmux over screen these days?

Plenty of reasons: Habits. Existing scripts. Muscle-memory. GNU/GPL over non-GNU/GPL. To mention a few. I've honestly not found a single feature in tmux which I need which isn't already covered (and imprinted in finger-memory) by GNU screen. On the flip side, I'd ask: What reason is there for a seasoned GNU screen user to bother switching from something proven, and which works?

These reasons are valid, but I'm more interested in technical reasons.

I switched to tmux when I needed to launch a lot of simultaneous jobs, categorized in three sessions (starting in "active", moving to "success" or "fail" when finished). I couldn't achieve it in screen at the time. The CLI interface of tmux is not very intuitive and I think somewhat inconsistent (maybe a bit like git?), but at least I could achieve what I wanted without major compromises.

After a quick google search my impression is that running a shell command in a particular GNU screen window is still painful.

Re: St – A simple terminal implementation for X

#124
post #99

Earlier quoted context omitted.

I kind of agree. But, how often do you change your settings after you've found the right ones? A minimalist would see runtime configuration as bloat.

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.

Re: St – A simple terminal implementation for X

#125

It really is fantastic to see a new _improvement_ on something like a terminal in 2017, that isn't written in Javascript / Coffeescript / Some other web technology that deploys 100+MB of libraries.

It's not new.

And it depends on how you define "improvement" since this lacks features many would want. And I'm talking about features in native apps, not web-tech apps.

Re: St – A simple terminal implementation for X

#126
post #86

Earlier quoted context omitted.

This. Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software. In fact, for the very same st, to change font, colour scheme, or hotkeys/shortcuts - one has to edit config.h file and recompile. There is no traditional text config file or "Preferences" menu. This might sound bizarre at first, but actually works as well as editing a text config file: config.h is…

It is still bizarre because not every user wants to and/or doesn't have the skills to do that.

[deleted]

Re: St – A simple terminal implementation for X

#127

Recompiling software to change options is utterly and totally ridiculous

Counter-example: Xmonad. Here's how I "configure" it:

Open ~/.xmonad/xmonad.hs. It's Haskell code, but frankly it reads like a configuration file, with a big list of shortcuts.

Edit the "code". You don't need to know Haskell, just follow the syntactic conventions you see there. Worst case, you have to search for configuration tips on the web.

Save xmonad.hs, hit the "recompile Xmonad" shortcut. You've now recompiled and restarted Xmonad, and all your windows are still where they were before. Application state survives recompilation.

Re: St – A simple terminal implementation for X

#128

Earlier quoted context omitted.

Alacritty uses the same argument against scrollback and tabs -- that these features should be handled by something like 'tmux': https://github.com/jwilm/alacritty

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

Most terminals have a column selection mode (e.g. Opt-click on Mac) hidden extremely deeply in documentation.

Re: St – A simple terminal implementation for X

#129

Interesting. I've been wanting a better terminal for some time. rxvt is super buggy, especially with clickable URLs. xfce4-terminal is better but select-to-copy is flaky and doesn't always copy the text I select. I really wanted st to work for me but something is wrong with the character sizing when using Source Code Pro (17pt) as the font. I installed this on my Arch laptop (a hidpi ThinkPad T460s) and something is…

I recommend termite, it is not bloated and quite simple, best composed with tiling window manager: https://wiki.archlinux.org/index.php/Termite

No screens there because there isn't anything to screen, it is just plain console without any GUI (supports scroll-back)

Re: St – A simple terminal implementation for X

#130
post #68
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.

You're clearly not their target audience if those are your takeaways. But there are lots of people out there who do prefer to recompile instead of configure and find suckless feature sets to be inline with their own requirements. To say that a product "sucks" because they don't cater specifically to your arbitrary desires is grossly unfair.

> To say that a product "sucks" because they don't cater specifically to your arbitrary desires is grossly unfair.

Then again, if they name their project(s) "suck less", it's completely fair to say it sucks. If they can have arbitrary standards about what constitutes suckage, why not us?

Post reply on HN