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.
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 very well structured and compilation only takes fraction of a second. Better yet, you're not constrained by opinions of previous commiters on what should be configurable and what - not. Which is the whole point, actually.
I can't believe they added serial line support and not scrollback. If you're going to claim bloat, serial line support definitely ranks lower on priority than scrollback.
Different people want different features. There's no way they're going to remain minimal and please everyone.
They have to choose the feature set, and if other programs can provide a feature that some users want, that seems like a feature ripe for pruning. I think they made the right choice.
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.
It is explained in the info that scrollback is implemented in dvtm. Duplicating the functionality would probably go against the general minimalist Suckless design philosophy.
Non-goals:
unlimited scrollback buffer (done by dvtm)
Alacritty uses the same argument against scrollback and tabs -- that these features should be handled by something like 'tmux': https://github.com/jwilm/alacritty
They use patches of the source code for plugin style functionality so it remains as minimal as they want and we can add features at will. There is one for scrollback
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".
[modifier]+shift+insert or [modifier]+shift+v are the default bindings for paste. [modifier] is most commonly Alt or Super (the Windows key). Keep in mind that your window manager might already have a binding for these, preventing them from working.
This 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.
As much as I love st, I had to stop using it recently. When using a bitmap font in tmux, large amounts of text sent to stdout bring my computer to a standstill. X is using 100% of a single core. I've switched to gnome-terminal and the issue is gone.
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.
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.
Even though I can't stand to use their software (or their aesthetic, or their ethos...) I'm very grateful that suckless exists. The source serves as an excellent reference if you want to learn, say, how a (non-trivial) window manager works, or how IRC is implemented in practice, or how to wrap the WebKit/GTK+ interface. The code is usually quite straightforward, and the lack of features/config makes it fast and easy to see what's going on.
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 instead of optimising, to reduce the perception of inefficiency; what's left is not necessarily efficient.
In fact, I don't remember the details now but I recall looking at the source for another one of the suckless applications and finding some pretty inefficient algorithms. I think the other comment here about st being CPU-intensive with high output rates is an example of this.
Ironically, one of the reasons I think mainstream software sucks is because newer versions also tend to remove configurability and features often for the same goal of reducing bloat.
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.
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.
emacs had a similar effect on me. Configuration is all in elisp so you can happily tumble down a rabbit hole of tweaking settings and find yourself learning all kinds of interesting lispy ideas.
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?
The code does unsafe things in signal handlers (vfprintf, for example), and hides some things in macros that I wouldn't expect to see hidden (like the assignment of the global "argv0" variable, defined in st.c, is assigned in a macro from arg.h).
I used st for a good year and it worked really well! I've switched recently for features like the ability to change the font size without recompiling, etc. Despite its spartan feature set, st is quite usable.
Bugs. When you work all day long in a terminal, you need it to be reliable. As I mentioned above, xfce4-terminal is what I normally use but select-to-copy doesn't work 100% of the time. This is super annoying. I'd switch to rxvt but it has its own problems. Despite having had terminals for so much longer, *nix has fallen behind macOS when it comes to terminal usability and reliability.
I work literally all day long in multiple fullscreen gnome-terminal instances, and I can't remember the last time I encountered a "bug". It literally never crashes, and works perfectly for my use case.
I can imagine there could be bugs in esoteric terminal emulation, but for the typical use case of "TERM=xterm-256color" (or screen-256color) it works perfectly for my use case.
There have been many times when vim starts glitching out or something because of the terminal emulator I'm using. Even well tested ones like X-term and gnome-terminal. I never had that problem using st.
We hack so much into a text interface it's really easy to accumulate bugs.
I use tmux+emacs inside gnome-terminal for 8+ hours a day.
I rarely (never?) see any "terminal glitching" except for the cases where I've done something absurdly wrong, like running a bash inside emacs-shell with the wrong setting for TERM.
Terminal emulation is essentially a solved problem (state machines and control code sets are small and well defined, there are many reference implementations and compatibility tests). If you see glitching, it's probably from what you're doing inside the terminal, not from the terminal itself.
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.
- I dispute "many devs/hackers use xterm". I switched away from xterm over 20 years ago, when it was clear that they were never going to have good support for anti-aliased fonts. I work heavily in the linux and with linux devs, and I can't remember the last time I saw someone using an xterm on a modern system.
- xterm is for exactly the case you describe: when all you have is "base X11" and you need a terminal. No crazy multi-gigabyte toolkit requirements. Its essentially a fallback/recovery tool for these cases, although I prefer just working on console when things get that bad.
- xterm's codebase is 30+ years old. "unmaintainable" seems like an overstatement, by a longshot.
This appears to be true (from other comments on terminal performance in this thread) but other VTE-based terminals (gnome-terminal) have high performance and work great on sub-1GHz class machines.
Readit News
Not everybody wishes to use a terminal multiplexer in all cases, either.
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 very well structured and compilation only takes fraction of a second. Better yet, you're not constrained by opinions of previous commiters on what should be configurable and what - not. Which is the whole point, actually.
They have to choose the feature set, and if other programs can provide a feature that some users want, that seems like a feature ripe for pruning. I think they made the right choice.
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.
>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.
FIFY
Really? Generally accepted by who? My unscientific personal tests show that Gnome Terminal is the fastest and lightest VTE.
In fact, I don't remember the details now but I recall looking at the source for another one of the suckless applications and finding some pretty inefficient algorithms. I think the other comment here about st being CPU-intensive with high output rates is an example of this.
Ironically, one of the reasons I think mainstream software sucks is because newer versions also tend to remove configurability and features often for the same goal of reducing bloat.
It's the same rationale that leads one to use a pen and paper rather than a note taking app.
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.
There is a general tabbing frontend that allows you to tab all sorts of applications: http://tools.suckless.org/tabbed.
I think it's fair to say suckless code is clean and minimalist. But it definitely isn't suckless.
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?
void (handler[LASTEvent]) (XEvent ) = { [ButtonPress] = buttonpress, [ConfigureRequest] = configurerequest, [DestroyNotify] = destroynotify, [EnterNotify] = enternotify, [LeaveNotify] = leavenotify, [KeyPress] = keypress, [MappingNotify] = mappingnotify, [MapRequest] = maprequest, [PropertyNotify] = propertynotify, [UnmapNotify] = unmapnotify };
What's this feature called?
http://stackoverflow.com/questions/18731707/why-does-c11-not...
From the st man page:
Deleted Comment
I can imagine there could be bugs in esoteric terminal emulation, but for the typical use case of "TERM=xterm-256color" (or screen-256color) it works perfectly for my use case.
We hack so much into a text interface it's really easy to accumulate bugs.
I rarely (never?) see any "terminal glitching" except for the cases where I've done something absurdly wrong, like running a bash inside emacs-shell with the wrong setting for TERM.
Terminal emulation is essentially a solved problem (state machines and control code sets are small and well defined, there are many reference implementations and compatibility tests). If you see glitching, it's probably from what you're doing inside the terminal, not from the terminal itself.
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.
- xterm is for exactly the case you describe: when all you have is "base X11" and you need a terminal. No crazy multi-gigabyte toolkit requirements. Its essentially a fallback/recovery tool for these cases, although I prefer just working on console when things get that bad.
- xterm's codebase is 30+ years old. "unmaintainable" seems like an overstatement, by a longshot.
This appears to be true (from other comments on terminal performance in this thread) but other VTE-based terminals (gnome-terminal) have high performance and work great on sub-1GHz class machines.