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.
Amen
St – A simple terminal implementation for X
111–120 of 223 posts
Re: St – A simple terminal implementation for X
#112I 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 find that most of their software is targeted towards beginner/intermediate hackers. Having to recompile /forces/ you to tinker with the source code. When I was learning how to code I would hack the shit out of my window manager (dwm), I learned a lot of C in the process. When you think about it that way, the "arbitrary limitations" on lines of code and everything else starts to make sense.
I agree most of their stuff isn't targeted toward the average user, just this small niche. Their browser, surf, doesn't even support tabs as far as I can remember.
Re: St – A simple terminal implementation for X
#113Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?
The way I see it, st is trying to replace xterm.
xterm is a de facto standard, in that you can sit down in front of a machine which appears to be running some flavour of Unix, it doesn't matter if it's Gnome, KDE, TWM, CDE, etc., GNU or BSD or Solaris or whatever, you'll probably be able to find xterm and work out the rest from there.
Many devs/hackers use xterm as their day-to-day terminal, and seem to approximate ANSI control code compliance with "works in xterm".
The problem with this situation, as mentioned on the st page, is that xterm is unmaintained and unmaintainable.
st is trying to be a maintainable replacement, making improvements like vector fonts, and not being shy about ignoring legacy/niche/solved-elsewhere features.
Re: St – A simple terminal implementation for X
#114Earlier quoted context omitted.
Finding the right settings is a relatively slow process. Also, finding the right values for 80% of the settings is fast, but fiddling with the rest can take time. Trying something new also becomes harder. For the vast majority of user-facing programs, run-time configuration is a must. A fancy GUI for it might be superfluous; a simple text file / command-line way to set options should always be available.
Compile times for me are 0.2 seconds. And there is a text file available, it's called config.h.
This sort of rules out binary distributions, or changing settings on a remote machine where you don't have the build dependencies installed. The latter may be irrelevant for a terminal emulator, but not for the general case.
Re: St – A simple terminal implementation for X
#115Earlier quoted context omitted.
It is still bizarre because not every user wants to and/or doesn't have the skills to do that.
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.
Agreed in general. (As a small counterpoint: I helped a beginner get familiar with Linux. We tried Ubuntu first, and she hated it. She switched to Arch and has been happy ever since.)
Re: St – A simple terminal implementation for X
#116Earlier quoted context omitted.
This, along with the generally accepted notion that Gnome Terminal is one of the slowest with output, puts the whole minimalism idea under a serious question. "Do one thing, but do it well ", the saying goes.
> the generally accepted notion that Gnome Terminal is one of the slowest with output Really? Generally accepted by who? My unscientific personal tests show that Gnome Terminal is the fastest and lightest VTE.
You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals.
yes | head -n 1000000 > two_megs.txt
time cat two_megs.txt
OTOH I can google up posts saying that pt shows good results in comparisons like that, apparently using a TTF font. Hopefully the bitmap font performance problem is not due to the general design, but a regression in a special case.
Re: St – A simple terminal implementation for X
#117Earlier 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.
What reasons are there not to use tmux over screen these days?
Re: St – A simple terminal implementation for X
#118This thread is like every thread on suckless software ever.
>This software, which specifically states that it caters to a niche, doesn't cater to my needs. I'm not going to consider thought that I might not be part of the niche it's catering to and complain about it instead.
Re: St – A simple terminal implementation for X
#119Earlier quoted context omitted.
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.
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?
Re: St – A simple terminal implementation for X
#120This thread is like every thread on suckless software ever. >This software, which specifically states that it caters to a niche, doesn't cater to my needs. I'm not going to consider thought that I might not be part of the niche it's catering to and complain about it instead.
>This thread is like every thread on HN ever.
FIFY