St – simple terminal
st.suckless.org
st.suckless.org
* ignoring C best practices:
/* prefix macros, please */
#define MIN(a, b) ((a) < (b) ? (a) : (b))
/* ME: ...so it parses a string? Doesn't pretty
* much every parser? Also, no prefix again. */
void
strparse(void) {
/*************************
* X11 CALLBACKS GO HERE
*************************/
* Here's a scenario broached by the README:
One goal of st is to only support what is really
needed. When you encounter a sequence which you
really need, implement it.
My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.
While I wouldn't call it a paragon of clarity, it basically follows the same style and organization as older Unix tools. In such cases, I find starting from main() and jumping around with ctags a useful strategy (after reading the globals and type definitions).
Oh, and I strongly agree about tests. Especially escape sequence parsing could benefit from fuzzing or other property-based testing approaches.
...it basically follows the same style and organization
as older Unix tools. In such cases, I find starting from
main() and jumping around with ctags a useful strategy
(after reading the globals and type definitions).
I forked it awhile back, this is the terminal I use now:
The way these things are usually implemented is that there is an interface of a "terminal" and implementations. As long as implementations do not break the abstraction and do not require modifications in the interface and other parts of code these implementations do not decrease internal software quality. They only cause bloatedness in terms of size of source code files which doesn't matter much.
I read something similar on Neovim's site, that they removed support of obsoleted architectures. And as an opposing example it seems that Linux kernel ships with drivers for very old devices and doesn't have plans for removing them.
Note that I don't know if in xterm's or vim's case implementations for obsolete subsystems cause real damage or only increase code size.
And when I was choosing a terminal implementation, I mostly benchmarked scrolling performance and looked at font rendering quality and xterm won. It is also actively maintained outside of Xorg [0].
I think as long as there is someone to maintain that driver, it doesn't get removed.
However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better".
FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fonts well, which I care strongly about. Its colour scheme is configurable and it's not tied to a desktop environment. It does use libvte from Gnome to implement the terminal emulator widget, and I'm OK with that. Less NIH please!
[1] After using Gnome-Terminal, Konsole, and RXVT-Unicode for a while. I doubt my quest has yet ended.
I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like config file, and I can easily have different font preferences on my laptop, my netbook and my desktop (all different screen sizes and different PPI).
FFW I use a spartan xmonad setup, and typically run one, or a handful of terminal windows, each with their own gnu screen instance (typically one local, and a few remote screen instances over ssh. Sometimes I'll have more than one view/windows to one screen session -- and sometimes I might have a screen for a chroot or local vm/container of some sort).
I do have one question though, why are the colors more pale in sakura than in xterm?
And is there any way to change it?
I'm wondering how people can compare these terminals mentioning speed, considering the actual performance is bound by libvte, and thus will be equally the same between roxterm, sakura, tilda, etc. What are they measuring?
xterm is quite fast (in the order of 3-5x faster) than any libvte-based terminal. Try doing something like "time [term] -c 'cat <bigfile>'", and try varying the scrollback size to have a real measure.
[u]rxvt in turn is even faster, especially with large scrollback buffers, which is the main (I could say only, really) reason I use it. As in, 10x faster than any libvte based terminal.
I also use suckless tools (with spectrwm), though I never had a reason to investigate st. urxvt supports fallback fonts, which for UTF-8 text is essential.
Not sure about others, but the first thing I test: dmesg; ps auxww; ls /dev
I only really care about apparent speed and, like I said, sakura was the only one that was comparable to xterm.
None of the other terminals I have tried (and only now I realize that they have libvte in common, thanks for that) have managed to perform acceptably (for me, at least).
https://code.launchpad.net/~kraiskil/sakura/colorsets/+merge...
If others have the same issue, it's: right click -> Options -> More -> Set Palette -> Xterm
More options are good.
The main difference with the other terminal emulators is that I can easily do horizontal and vertical window splits.
Many use screen or tmux for that but I find them too limiting, especially in their scrollback implementation.
How far you take it depends on what you'd want out of such a tool. Simple "New Shell", "Close Shell" buttons would be easy; overlaying draggable partitions would be more effort, and less elegant, but still do-able.
In that case you don't even have to rearrange windows - each new window automatically takes part in the split. And you can combine terminal sessions, browser, etc. as you wish. I find this a lot easier to use than screen/tmux.
I used to be happy just running multiple xterms, but I've been using Linux again recently and found myself a bit unhappy with that. I think due to advancing age I'm just finding it hard to cope with lots of windows. Keeping on top of them is a pain.
it's about removing features, and then rewriting.
for example, it doesn't even have scroll back! ... which is the reason i don't care much for it.
Ok, I am interested.
> How do I scroll back up?
> - Using a terminal multiplexer [shows tmux example]
Emm... tmux is a 32K lines of code. That kind of defeats the purpose of the opening paragraph.
In this view, I guess it's not the terminal's duty to do multiplexing, scrolling etc. Tmux is meant to do the job, so its codebase size should not be added together with st's. They're separate software, each doing its thing and doing it well, an approach completely opposite to that of other software (e.g. emacs) that do lots of things.
1 tmux is needed to handle multiplexing
2 tmux also handles scrolling
3 if you need tmux for other things already, you don't need scrolling in the terminal emulator
I wouldn't say that, by this reasoning, it is the right place to implement scrolling, just that, since it's a solved problem, re-implementing it would be a useless duplication of effort.
But in this specific case I'd concede that the way tmux scrolls is not at all comparable with how a X terminal emulator would be expected to scroll.
Multiplexers accept drawing commands from multiple applications and combine them into one "root window".
By analogy, Linux launches a single process (init) which then handles all the others. The init system is not a kernel.
On the other hand, X11 doesn't just render a single root window (eg. controlled by the window manager). Instead it allows multiple clients to each draw to multiple windows, and the window manager performs a lot of back-and-forth communication with X to keep track of them.
In that sense X is certainly doing more than it should. Is tmux? Probably. Hell, it contains a mode-line with a clock! Why not use the existing multiplexing to offer a "sticky" single-line window, in which we can run some arbitrary status-displaying program?
Multiplexers accept drawing commands from multiple applications and combine them into one "root window".
If we accept for the sake of discussion that rendering to a "device" is the distinguishing characteristic of terminal emulators here, rather than, say, emulating terminals (which tmux certainly does), can't you think of another terminal emulator as such a device?
I can't really tell how the Linux init analogy is valid and what your point of making it is. Is the init system a "kernel emulator" or a "kernel multiplexer"?
It depends whether you think "Save to PDF" printer drivers really are printing. Does tmux "certainly" emulate a terminal, given that I can't observe any of the output or send it any input without assistance from another terminal emulator, like st?
> I can't really tell how the Linux init analogy is valid and what your point of making it is. Is the init system a "kernel emulator" or a "kernel multiplexer"?
The init system is like a "process multiplexer". The kernel only starts one process; if we tell it to start bash, we have a shell but not much else (until we fork stuff off manually). If we tell it to start an init system/daemon then we get a whole bunch of processes started for us during boot.
Likewise, when we start a terminal emulator we can run bash to get a single shell session, or we can run a multiplexer to get many.
How does it depend on that? When you express an argument as an analogy without further explanation you lose a lot of information.
> Does tmux "certainly" emulate a terminal, given that I can't observe any of the output or send it any input without assistance from another terminal emulator, like st?
It "certainly" emulates terminals in that it behaves like one to the user and to programs that use it as a terminal, just like xterm or st. Whether the platform it uses for presenting this to the user is X11 or a terminal/another terminal emulator seems irrelevant to me.
> The init system is like a "process multiplexer".
It isn't a process multiplexer. How is it "like" a process multiplexer? init maybe starts a bunch of processes, but it doesn't do any multiplexing or even manage their communication at all.
> Likewise, when we start a terminal emulator we can run bash to get a single shell session, or we can run a multiplexer to get many.
You don't need to use a terminal multiplexer to have multiple shell sessions.
It's easy to count, since it's mostly a single file: http://git.suckless.org/st/tree/st.c. :)
It's modern, incredibly fast (could even be GPU-accelerated), fancy (if you want it to) and stable.
See previous discussion: https://news.ycombinator.com/item?id=5438089
I'm not sure whether that's the right thing to do but it's the way they work.
That said, I moved on to ROXterm because I was having encoding issues with a couple of programs I use. St is worth consideration as an uber-minimalist terminal though... it's very fast. Even on ancient hardware it launches essentially instantly because it's not loading any large libraries like GTK. St is pretty fun to hack on, too.
You've clearly misunderstood the point st is trying to make. Not only is it not critical, it's a bad idea for a terminal to store and scroll history! Yes it's nice to have a history to scroll through, but other programs (screen, tmux, Emacs, etc.) are much better at doing that than terminal emulators are!
For many people, like sysadmins, it's crucial that shells can be accessed over a network. Does that mean terminal emulators should build networking into their code? No, since SSH already does an excellent job.
For many disabled people, it's crucial that shells can be speech-driven. Does that mean terminal emulators should build speech recognition into their code? No, since external systems (Sphinx, etc.) are already tackling this problem.
Of course, from an "end user" perspective it would be nice to have "one application" which does all this. The beauty of the UNIX philosphy is that we can write such an application easily (untested, but you get the idea):
#!/bin/sh
if zenity --entry \
--title="New Terminal" \
--text="Enter the shell URL (blank for local shell)" \
then st -e "tmux -c ssh '$?'"
else st -e "tmux"
fiAs such, having an additional, useless layer of scrollback on the client is both confusing and pointless, so they removed it.
I use Sakura. https://launchpad.net/sakura
But what is wrong with Gnome-Terminal? For me it works well enough out of the box. I literally didn't do anything beside increasing the scroll buffer and haven't run into enough troubles yet to switch.
The dependencies: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/g...
If you're using Gnome, you probably have those already so it's no big deal. The same goes for Konsole in KDE: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/k...
If not, pulling in a few hundred MB of dependencies for a terminal emulator seems distasteful. st is much more self-contained: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
That's why st is usually compared to xterm; they're small, basic and desktop-agnostic.
Apart, Windows needs a good terminal. Console2 and ConEmu, not end to work fine... I get strange issues with colors every time that I connect to ssh against a GNU/Linux machine and open vim.
Windows + Vim: https://i.imgur.com/soTIhNy.png
SSH + Vim: https://i.imgur.com/aLs9ACy.png
I really wish there was a better way to deal with this (I have the same problem with rxvt-unicode-256color). I'm obviously not going to make install a graphical terminal emulator on some random server I'm logging into.
tic -s st.info
For the machines I regularly use I have terminfo files in my dotfiles git repo.
alias ssh='env TERM=xterm-256color ssh'If it takes more time for the graphical terminal to give me a usable prompt than alt+Fx then that particular terminal failed.
st -f DejaVuSansMono-12Or just use tmux for "tabs", you'll need something like that anyway for scrollback, etc.