St – A simple terminal implementation for X | Hacker News Reader

St – A simple terminal implementation for X

st.suckless.org

274 pointspmoriarty217 comments

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.

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.

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).

I just use tmux's native copy/paste mechanism, using the keyboard. Using that it's possible to get the full scrollback buffer, or any part of it.

And I want to paste it into a non-terminal application running locally while the tmux is on a remote host?

You can always use ssh and something like xclip or pbcopy.

Also, I always use mosh for ssh (when possible) so that I can recover my connection if I run into network issues. Since mosh works by synchronizing a virtual screen, I don't get scrollback at all without tmux or the like.

This. I like terminal scrollback but it's gone for me.

I just added a feature to tmux-git that makes the tmux clipboard propagate up into higher clipboards for nested tmux. https://github.com/tmux/tmux/commit/4ede35c48c089abe3fca0d94...

Keep in mind that your terminfo has to support this, so make sure your ncurses-term package is the latest release from Jan 28.

I also made a patch for st to support OSC 52 propagation into Xorg, but it was rejected by the st maintainers because it uses base64 (as the OSC de-facto spec from xterm dictates).

The patch for st is however in a branch of the Wayland-fork of st

https://github.com/michaelforney/st/tree/selection

Another option if you use nested copies of tmux is to use this feature to get the remote clipboard into the local one, then yank with xclip.

'xclip -selection clipboard' works fine for this use case.

[Edit] Assuming you have SSH configured to forward to your local X server [0].

[0] http://unix.stackexchange.com/a/16697

Unfortunately many ssh servers gratuitously disallow X11 forwarding; tcp forwarding can accomplish the same, but then setting up DISPLAY &ct. need to be done manually.

In the latest git builds of tmux (with the latest terminfo db from ncurses), you can have clipboards propagate from remote tmux to local tmux (nested configuration) using the new OSC52 control sequence implemented in a patch from 2 weeks ago.

Also, if your terminal emulator (rxvt, xterm on Linux and mintty on Windows) support OSC52 escape sequences for clipboard setting, this means you don't need X11 forwarding anymore, since you can set your X11 clipboard from tmux.

If anyone can help me get in touch with the libvte people, I want to patch OSC 52 support in there as well, since this is a great feature that should _not_ be relying on X11 forwarding or whatever.

And it's slow.

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

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.

My first thought, as well.

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?

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.

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

Sure. And let's go full circle while we're at it: GNU screen supports connecting directly to a serial device :)

Last I checked tmux doesn't.

Other reasons have been listed already, but if you're an iTerm2 user, another strong reason to use tmux over screen is the fact tmux can use "native windows" in macOS and you have deep integrations between the two. It's especially useful with remote tmux sessions.

Can you describe the scenario where you can't use screen but can use a terminal emulator with serial support? I've done a ton of work using serial (mostly routers and switches, but some other stuff too) and never found an instance where that didn't work.

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-...

But if you're going to use screen to connect to your serial port, what was the point in adding serial to support to the terminal emulator?

To make the argument that scrollback is bloat is insane if you at the same time add serial support but need scrollback for serial usage, so you use screen instead which had both serial support and scrollback.

So why isn't screen or minicom a valid reason to "avoid bloat" in supporting a serial line interface and scrollback support natively isn't?

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)

Interesting. Thanks for the pointer to dvtm. I'm not sure I can see using it when I'm already fairly hooked on tmux, but it does seem kind of nice.

Scrollback is implemented as a patch: http://st.suckless.org/patches/scrollback

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 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.

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.

Exactly. I would never use it, but I'm perfectly alright having something targeting a niche perfectly. It's better than trying to please everybody and ending up being "meh".

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, people do things the way they know how until they decide to learn more. Think of how many time's you've seen some family member slowly select file-save without ever figuring out ctrl-s.

if you don't like it than fork it

I find in hard to fork human behavior and have anything one might consider a good adoption rate.

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.)

What lisaberlin wrote applies - suckless is like Unix: user friendly, just very selective about who it decides to make friends with.

But in this case, I would disagree. The file is quite readable (way more than most text config files I've seen), and the single command to compile is even included in the README. If you're the kind of person that purposefully downloads a new terminal, rather than using the built-in one, you can probably configure st just fine.

Seems like kind of a pretentious choice... they've structured their program so the config file is a .h file just so you can feel cool when you compile it to change font size?

I suspect it's not so you feel cool, but because it means the program doesn't need a parser for config files, and because it's more flexible.

parserless configuration is easily achieved with stuff like envdir: https://cr.yp.to/daemontools/envdir.html

That just parses environment variables, instead of files.

Not to mention that it's yet another dependency, which is another thing that's avoided by doing configuration through a header file.

> suckless is like Unix: user friendly, just very selective about who it decides to make friends with

I like to use the term "super-user friendly", as a compliment.

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.

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.

What I dislike about this, is that I have to manually track new versions -- rather than just have my package manager pull in new versions that read a `st.conf` file.

Also, I like different colors for different things. Production server terminals look different that staging server terminals that look different than development terminals.

As floatboth pointed out above, it is possible to use a shell script [1] to dynamically change terminal colour mapping. Add this as "LocalCommand" to appropriate "Host staging-foo" and "Host production-bar" sections of the ~/.ssh/config file, and you're all set.

[1] https://github.com/chriskempson/base16-shell

Gentoo's package manager (Portage) deals with this quite nicely for packages like st [1].

Both custom patches and config.h changes can be saved in the package manager, which will then apply them automatically to new versions.

[1] https://packages.gentoo.org/packages/x11-terms/st

> Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software.

I don't get it. This patch increases the code base by merely 60 lines of code (104 insertions, 44 deletions).

Is 60 lines already considered bloat, in a verbose language like C?

Also, is this meant to lead to fewer complexity? Maintaining the patch separately from the code base is nothing but cumbersome. Essentially this is a long-time feature branch, which is a well-known anti-pattern regarding software quality and maintenance. What if there are more and more of such patches? What if they overlap and can't be applied together? In a central code base these formal conflicts would be resolved once and for everyone, early on.

I would have expected this feature (and its code) to be enabled/disabled by a single #define in config.h. That would be more consistent with the suckless philosophy of configuration. Or, reducing that bloat by simply enabling it always.

>Is 60 lines already considered bloat, in a verbose language like C?

It's more about features. tmux and screen are widely used, so a lot of people won't need that functionality to be duplicated. Keeping extra features separate lets the users pick and choose what they want.

It's also worth noting that suckless's software is not meant for someone who wants a turnkey solution. It's meant to be customized by most every user.

> Is 60 lines already considered bloat, in a verbose language like C?

Due to high code quality, removing even 10 lines is an achievement for suckless.org projects. Try it yourself and submit a patch to mailing list if you succeed.

> Also, is this meant to lead to fewer complexity? Maintaining the patch separately from the code base is nothing but cumbersome.

Maintaining feature as a patch prevents you from weaving it deep inside the code, adding hooks here and there just to make it work. It is harder to do, but it is the right way to make sure all feature related logic is kept in one place.

I have some pet suckless inspired projects. During development I introduced some useless features such as pthread support just because I learned about them. Then once I realized they are useless I removed them. It greatly improved code structure.

> Maintaining feature as a patch prevents you from weaving it deep inside the code, adding hooks here and there just to make it work. It is harder to do, but it is the right way to make sure all feature related logic is kept in one place.

I'm used to achieve this by keeping each topic in a separate module (in C: function or file, in other languages: module, class, whatever). You'd then have clear entry points into that module.

Interestingly, the given patch isn't structured like that. So I'd argue that code would benefit from becoming a first-class citizen in the code base. As a patch it just gives the illusion of a well-separated feature. (Because a patch file is always a single file, no matter how much the changes are scattered around in the code base.)

> I have some pet suckless inspired projects. During development I introduced some useless features such as pthread support just because I learned about them. Then once I realized they are useless I removed them. It greatly improved code structure.

I fully agree that removing useless features does not only shorten, but simplify code. However, given that by far not everybody uses screen/tmux, I disagree with the "scrolling is useless" assumption here.

> to change font, colour scheme, or hotkeys/shortcuts

No, you don't have to recompile it. For shortcuts, sure, but I haven't used any st shortcuts besides font size +/-.

Colors can be changed via the shell e.g. https://github.com/chriskempson/base16-shell and the font is passed via the -f flag.

...and does it not support pasting from the X clipboard ? It's not accepting in my installation, anyway... :/

I can paste in to it from the X clipboard using SHIFT-INSERT just fine.

[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.

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.

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).

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".

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.

>This thread is like every thread on HN ever.

FIFY

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.

Compared to Terminal.app and iTerm2, VTE (the widget underlying Gnome Terminal) is blazing fast.

> 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

You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc.

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.

Huh, interesting results on my machine:

    urxvt 0.233
    gnome 0.474
    st    0.515
    xterm 1:13.87

times are total real time, in seconds, seem repeatable from a few runs.

I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?

Minimalism is a tempting proxy for performance, but it often isn't. rg/ag/pt aren't some of the fastest file searchers around because they're short and don't pull cool tricks.

Another example: GNU vs BSD grep, from the author's mouth: https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

Regex matching: https://swtch.com/~rsc/regexp/regexp1.html

(It's arguable that a backtracking implementation is not the simplest, although I think it is -- and even if it is, a FSA compiler clearly isn't!)

And, finally: people tell me Clojure is slow, and I tell them that it lets me write correct concurrent algorithms I understand. (See alioth shootout results.)

It could have to do with that xterm is trying to faithfully emulate an actual terminal (viz., VT220 with extensions) by replicating the VT's internal state machine, whereas libvte is trying to approximate the behavior of xterm and cutting corners as it does so.

Note that while libvte seems to have greater throughput, its latency is terrible compared to xterm.

xterm is showing all data. That's why it's slower. For a fair comparison, you should set the fastScroll X resource, which will allow xterm to suppress screen refresh.

Yikes, consider running that through callgrind or something and sending them the output.

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.

Well, I mean that's what they're doing as well. They call features other people use and require "bloat" and pretty much say they all suck.

I think it's fair to say suckless code is clean and minimalist. But it definitely isn't suckless.

I think they're not trying to be suckless, but merely to suck less.

First of all it is "suck less" not "suckless". ie "less bloat/features" rather than "hey look at our perfect software". This is a point reiterated on their site repeatedly (including the <title> tag on their home page: http://suckless.org/)

Secondly, it's all very tongue in cheek. After all it's aimed at the OpenBSD crowd and like minded people. It's not really meant to be taken literally by the general computing audience - not even within the wider FOSS community.

Lastly it's sad day for HN when negative comments get up-voted and positive comments defending niche software get down-voted. What happened to respecting our peers and acknowledging the massively wide range of personal preferences and usage habits?

> What happened to respecting our peers and acknowledging the massively wide range of personal preferences and usage habits?

I absolutely wasn't trying to be disparaging of them. I understand that there are people who love their work, and I love some of their software (dmenu).

My point was more toward the parent I was replying to - i.e., that the message from the suck-less crowd that other pieces of software "suck" is just an opinion. In the same way that they think (for example) the KDE desktop sucks, it's allowed to think that their products suck.

But I suppose that it can be seen as disrespectful, and I understand that. There is definitely room for airing one's opinion in a less inflammatory way.

> 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?

Extending `st` with a config reader is super duper easy.

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.

> 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?

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.

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.

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 don't use C for a couple of years and I see this:

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?

Designated initializers. It's in C99.

Thanks. Oddly not in the C++ standard:

http://stackoverflow.com/questions/18731707/why-does-c11-not...

Yes it's strange, it's one of the reason I stopped using C++ as a matter of fact. Given the innate amount of code required in C++ constructor to initialize objects, you'd think that would be very handy.

BTW, shameless plug, but my own simavr uses these C99 features as more or less the whole basic structure on how multiple cores are described, see a sample core declaration [0] for example. The beauty is that there is no code involved in the declaration, it'll be 'const' too. Imagine the boilerplate you'd need to do that in C++!

[0]: https://github.com/buserror/simavr/blob/master/simavr/cores/...

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.

What do you use now? Keyboard shortcut for font size change is a must for me.

"Keyboard shortcut for font size change is a must for me."

From the st man page:

       Alt-Shift-Page Up
              Increase font size.

       Alt-Shift-Page Down
              Decrease font size.

       Alt-Shift-Home
              Reset to default font size.

Some don't read the man pages.

Not sure how I missed that, but it's been a while since I tried St so maybe it wasn't there then.

I use konsole which is better than I found gnome-terminal to be and less klunky than I was expecting

You don't have to recompile st in order to change fonts. You can just pass it the -f flag with the font you want to use.

Given their focus on being lean, it's more like SPARTAN!! feature set rather than just a plain spartan feature set. :)

Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?

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.

Have you considered using neovim?

Currently neovim is not even close in stability to vim.

Based on what criteria and experiences? I've been running it for a year with a slew of plugins for example and haven't experienced a single hiccup.

Big part my plugins just do not work still in neovim.

Try spartan way for vim too. Used to have huge list of plugins and exotic vim hacks in my `.vimrc`, nowadays ain't even using plugin manager. `:colorscheme blue` and off you go.

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.

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.

Termite is pretty good and bug-free in my experience.

Plug: I maintain a fork of termite which doesn't require Daniel's patched VTE3 fork; and guts most of the exotic vimmy features.

I really like VTE's behaviour; even if the performance is a bit worse than XTerm (though worlds ahead of what I've seen on OSX with iTerm2 and Terminal.app). I rely on using iBus input methods in the terminal on a daily basis, and VTE handles this wonderfully.

https://github.com/xorgy/termite

I've also gutted a lot of stuff from termite in my own fork (overaly, vi mode, clickable urls) and it definitely makes for a lovely minimalistic terminal. I'm thankful for termite being so simple (granted the lifting is done by a lib) that this is possible without much effort.

I just wish I could log the scrollback buffer so that I could open an actual editor on it, but I don't think libvte exposes anything to do this.

Hey, thanks for the tip on Termite. I've been using it since reading your comment and it's awesome. Cut and paste and URL opening both work flawlessly!

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.

Its funny, but I have had fewer stability issues with gnome-terminal than I have had with st. Seems like most people have the opposite experience.

I care about functionality. Stuff like true color support helps reduce strain to the eyes.

Performance.

Not everyone has the latest and greatest machine.

Are you saying that xterm has poor performance?

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.

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.

xterm is actively maintained and cares about a whole pile of corner cases that were enough for users to raise valid bugs. See the changelog: http://invisible-island.net/xterm/xterm.log.html

- 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.

Recompiling software to change options is utterly and totally ridiculous

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.

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.

> This sort of rules out binary distributions

You can install software without a package manager.

In my experience if one can edit config files on a system, one has room to install a minimal C compiler. And one can distribute things in a binary form even if the config requires compilation. Consider distributing an application as a library or object files when the target machine needs to compile and link only the config file.

The difference between a config file that's dynamically loaded and a file that is compiled in is surprisingly small, as long as the compile times are very fast. First noticed that when using XMonad: one shortcut to recompile it and reload it, that's just as fast as editing configuration of any other window manager.

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 rather complicated way to tune font size compared to a slider.

And on that note, while I admire ST for its simplicity, I've been a happy user of Sakura for the past few years (though, sadly not on windows 10... I've yet to find a really good console for w10).

https://launchpad.net/sakura (page down at the moment...)

http://www.pleyades.net/david/projects/sakura

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.

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.

Well, the promise of the Linux subsystem is kind of to not having to run half-ports like cygwin in the first place... Still, appreciate the tip. Any idea how well that works on a high-resolution display like the surface 4?

No idea. But it works great for me with a resolution of 1920x1080. I don't see why it wouldn't work with a higher resolution display.

Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.

What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave how we want.

Let's also remember that a great deal of software you don't even think about also runs this way; they'll have config flags to add and remove features at compile time (run Gentoo or FreeBSD ports for a few weeks and you'll see what I mean).

So having hardcoded options isnt that ridiculous nor uncommon on Linux. However mainstream desktop distros do a good job at hiding that from their users by picking sane defaults for them.

> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.

Cool... Now I know that it's not just me that does this then. :)

Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

> Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation.

Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)

Does not apply to all software. It is just a terminal (and pretty fast terminal). I don't need change options for ST often. Changed probably few times just after upgrade to new version.

More often options are changed on the shell (ZSH in my case) Then even more often on tmux.

Why? It’s perfectly convenient if your software compiles quickly (st does), and saves having to make guesses about configuration file syntax.

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.

I kinda love it. It's just so gloriously economical, and it clearly defines their intended user base.

That xterm README is from 1991. I believe it has improved a lot since.

It is also, in practice, actively maintained and gets bugfixes. It turns out there are a metric buttload of obscure corner cases that do need to work right.

Here's the changelog: http://invisible-island.net/xterm/xterm.log.html

xterm is addressing a vastly broader audience than st.

Which btw was my problem with it when using st. Corner cases like using nano under ssh just plainly did not work. Or copying stuff from the terminal that got linewrapped, if I get that wrap as a linebreak in the copy buffer it destroys the password I just copied, making it hard to use pass.

Personally I am enjoying terminology very much.

https://www.enlightenment.org/about-terminology

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.

I love Terminology, and the entire 90s vibe of EFL and Enlightenment generally. So unashamedly not flat design in a world of Jony Ive / Google Material Design conformity.

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

Yes, I am!

It's honestly not the most important limitation of Terminology (except maybe to you). It doesn't support re-ordering or renaming tabs. It doesn't support searching into scrollback. It doesn't fetch terminfo data.

It's still the best terminal emulator out there. Incredibly fast in software-only, even better when hardware accelerated, skinnable and configurable.

This is my favourite terminal. I have it configured to run tmux, and couldn't be happier. Lightning-fast, stable as can be, it gets out of my way and lets me work.

I've been using it as my main terminal for I think over 2 years, selected my patches, tweaked it a little. Great hackable little thing with comprehensible code.

same here. my only gripe is that it seemingly doesn't support firacode (https://github.com/tonsky/FiraCode)

xterm's support for the Tek graphics terminal is actually quite neat, since you can use it with for example gnuplot to plot things over a (bad) SSH connection.

Also there is still some niche software that still requires it (for example IRAF which sadly is still going strong in the astronomy community).

Indeed it is and not just for that. When I developed the firmware for our my company's laser product I exhaustively used the Tek graphics support for debugging purposes. Kind of neat if you've got only a serial connection and have to plot graphs. Much better than dumping it into a file and plotting it with gnuplot.

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 seriously screwy with the fonts. At top is xfce4-termina; on the bottom is st:

http://imgur.com/a/8ALoS

I would report this to the author but I don't see any way to do so.

> rxvt is super buggy

Which one are you using? AFAIK urxvt is the only maintained fork. I could be wrong.

> I would report this to the author but I don't see any way to do so.

http://suckless.org/community

You'll probably get yelled at to fix your font config if you report it, though.

They're pretty big on "This is not #support. Post patch or GTFO" last I was there.

The two terminals in your screenshots are using different fonts.

Notice the dotted zero in the top terminal (xfce4-terminal) and no dotted zero in the bottom terminal (st).

I suspect st is not recognizing the font name you're giving it, and to fix it you have to play around with different ways to telling st the name of your font. What worked for me for the Inconsolata font was "st -f Inconsolata" or "st -f Inconsolata:size=11".

st does this when you don't give it the right font path and config. There is one compiled in, and that's what it's using if you aren't passing a font when you start it. Right now, whatever font it's trying to use doesn't exist, and your screenshot is a typical result of that.

> I would report this to the author but I don't see any way to do so.

Godspeed, I moved away from all suckless software because the developers are all massive jerks. They'll ignore your bug reports unless you spend an unreasonable amount of time doing intricate debugging, and if you refuse they'll be sure to remember your name and act hostile if you ever go back into their IRC. That's been my experience with Surf and something else (I don't remember what, but it wasn't st) anyways.

Well to be fair, it's in their name: suck less. It might be less, but it definitely sucks :-)

Try looking for the actual font name with "fc-list | grep -i source", maybe it is not what you're expecting.

A few months ago I was having trouble with getting some TTF BIOS fonts recognized by urxvt and fc-list made me realize that I should've escaped a couple dashes in the font name.

In config.h:

  /*
   * appearance
   *
   * font: see http://freedesktop.org/software/fontconfig/fontconfig-user.html
   */
   static char font[] = "Liberation Mono:pixelsize=12:antialias=true:autohint=true";

Try to specify font name in this format.

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)

I find terminal emulators on Linux to be woefully inadequate after getting used to iTerm2 on OS X. Can anyone recommend a Linux terminal emulator that even comes close in terms of features and performance?

What features do you need in iTerm2 that you find lacking in the Linux terminal emulators you've tried?

I second this out of true curiosity. I have tried and never found any love in my heart for iTerm2. It just feels clunky and bloated to me.

Last time I asked, someone said: "many features, but I like cmd-click to open path". After reading [1] I see that all it does is loading hipster-oriented "features" into your brain. Almost every feature is useless if you're doing any amount of actual work with decent cli tools. But for playing a hacker it is pretty cool.

[1] https://www.iterm2.com/features.html

There's nothing wrong with features that give you access to the wider operating system. Like it or not, the modern operating system is more than just terminals and CLI tools, and there's no reason to be condescending to those who don't live exclusively in the terminal.

A large part of what makes iTerm2 popular is how well it works in tandem with MacOS. Things like cmd+click to open (useful because you can use it on data that was spat out from a previous command invocation), paste filtering, and the fantastic built-in multiplexer/tabbing system.

That said, most of what makes MacOS users like iTerm2 just wouldn't be as useful on any other operating system, because its so tightly coupled to the wider OS.

I do not think that it does work well with OSX.

Autocompletion is on <⌘-;> (spell check) instead of <Esc>, and it works strangely: "$ ls trunk/<cmd-;>" suggests other directories around trunk (like tags and branches), when it should list trunk's contents. Cmd-click on path cannot go to partial path. It also cannot "open in app", only in default app (^cmd-click doesn't help). I always can select or triple-click and "$ open [-a ...] <cmd-v><cr>" to do that; or stop being fool and just type "open ." and do whatever I need right in Finder. Colored tab's colors blend to barely visible when deactivated. Changing color themes in settings does nothing at all.

I'm not arguing that features aren't needed. I'm arguing the hyping of little-to-no working "features" that it tries to sell in place of REAL tools and .files that were there for decades.

I don't know if the "cmd-click to open path" is a feature that's already built in to any Linux terminal (though I wouldn't be at all surprised if it was, considering how many terminals Linux has).

You can probably do something like it with urxvt's perl extensions. You could also just double-click to copy the path to the X primary selection and then use a keyboard macro to open the path in the primary selection in your file browser, or whatever.

On my pretty stock debian system, my terminal in i3 does the cmd-click bit.

Not OP, but some cool features I haven't seen in Linux:

- Quadruple-click smart selection

- "Selection respects soft boundaries" for selecting within a tmux pane

- "Rum coprocess" on keyboard shortcut, which allows doing stuff like http://brettterpstra.com/2014/11/14/safer-command-line-paste...

I just checked, and gnome-terminal doesn't even have split-pane. What do you guys use, anyway?

Quadruple-click smart selection should be doable with urxt's perl extension feature.

Selecting within a tmux pane: you got me on that one. I'm not aware of a terminal that does that, but again, it should be possible to do with urxvt's perl extension feature.

Regarding the "safer command line paste", Linux can do the same with bracketed paste mode.[1]

For splitting panes, I just use tmux, vim, or emacs.

[1] - https://cirw.in/blog/bracketed-paste

I've been happy with gnome-terminal :)

Lilyterm works well for me but I don't know what features you are looking for.

If you're looking for native tmux tabs, Terminator unstable has initial support, for instance.

If you're looking for things like toolbelt, or built-in regexp highlighting, or other (arguably nice) bells and whistles, I suspect most of them would be provided by separate utilities. (Yes, it's a distant echo of the "Unix way".)

Bookmarks in scrollback are neat, though, and cannot be easily added by a third party. I don't remember an implementation, though.

Konsole?

Performance? I can't think of a terminal emulator which performs worse than iTerm2 on any platform; other than maybe Cool Retro Term, but I don't think performance was much of a consideration there in the first place.

I was always happy with gnome-terminal.

But then someone recommended Terminator and haven't gone back since :) It feels like gnome-terminal on steroids. Love the multipane stuff.

rxvt-unicode (urxvt)?

Terminology

I'm working on a new terminal which takes a few cues from iTerm2 and also adds other unique features. It is not up to production level quality like iTerm2 but you are more than welcome to try it out.

Extraterm -> https://github.com/sedwards2009/extraterm

The visual tour page explains some of the ideas present. https://github.com/sedwards2009/extraterm/blob/master/docs/t...

previous discussion: https://news.ycombinator.com/item?id=8661282

Is there a full-screen mode? I often use it with gnome-terminal and the vim-goyo plugin, it's pretty neat.

using i3 win+F here

THIS!

I wish apps would stop implementing their own fullscreen functionality/hotkeys/etc, and we could all start relying on window managers (or DE's) to provide this.

On-topic, I really like that if I super+F firefox, it actually behaves full-screenish and hides the its bars. I wish most apps would do this.

F11 does not work with gnome, I thought it was part of the Gnome DE and not implemented in gnome-terminal...

scrolling through http://git.suckless.org/st/plain/st.c I stumbled upon

    #define LEN(a) (sizeof(a) / sizeof(a)[0])

I know precompiler magic is hard, and my C aint the best

but it makes me wonder if the parens at the end make sense - shouldn't it be something like

    #define LEN(a) (sizeof(a) / sizeof((a)[0]))

also asked here https://stackoverflow.com/questions/42001665/is-this-a-plain...

i'm not saying that the way they wrote it makes sense, but you have to remember that sizeof is actually an operator and not a function.

just got basically the same answer on stackoverflow - sizeof is an operator -> works w/o parens - makes sense - that's why i'm asking

I use st & I made a video about tmux since I am dependent on it :) https://www.youtube.com/watch?v=HCvFw3hfvxU

I love using this terminal. It is extremely fast and does what it suppose to perfectly.

Already have tmux which provides scollback, and I even get that in a try.

Only if surf was functional enough to be my daily driver.

> xterm is bloated and unmaintainable.

which is why I use rxvt-unicode

ITT: A lot of hate about suckless software and harsh ideological discussion.

There, I just saved you a ton of time :) Go read the next story.

st lack support for a fallback font, so I can't have emoji on my terminal, and that really breaks my workflow because I'm sure I'll eventually need to see an emoji on the terminal for some reason, so I've dedicated hours tweaking this just to be ready for that moment.

This should be accomplishable by tweaking fontconfig.

I would keep using Konsole/Yakuake

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.

st has been around for a few years now. But yes, it's good to see a decent, lightweight terminal emulator being somewhat actively maintained.

Amen

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.

What exactly is the improvement here? a small code base? Is that all?

Reply on news.ycombinator.com