Back in 2018, I made a two part series about terminal emulators that was actually pretty painful to write. So I'm not going to retry this here, not at all. Especially since I'm not submitting this to the excellent LWN editors so I can get away with not being very good at writing. Phew.

Still, it seems my future self will thank me for collecting my thoughts on the terminal emulators I have found out about since I wrote that article. Back then, Wayland was not quite at the level where it is now, being the default in Fedora (2016), Debian (2019), RedHat (2019), and Ubuntu (2021). Also, a bunch of folks thought they would solve everything by using OpenGL for rendering. Let's see how things stack up.

  1. Recap
  2. Requirements
  3. Candidates
  4. Candidates not considered
  5. Next steps
  6. No conclusion

Recap

In the previous article, I touched on those projects:

Terminal Changes since review
Alacritty releases! scrollback, better latency, URL launcher, clipboard support, still not in Debian, but close
GNOME Terminal not much? couldn't find a changelog
Konsole outdated changelog, color, image previews, clickable files, multi-input, SSH plugin, sixel images
mlterm long changelog but: supports console mode (like GNU screen?!), Wayland support through libvte, sixel graphics, zmodem, mosh (!)
pterm changes: Wayland support
st unparseable changelog, suggests scroll(1) or scrollback.patch for scrollback now
Terminator moved to GitHub, Python 3 support, not being dead
urxvt no significant changes, a single release, still in CVS!
Xfce Terminal hard to parse changelog, presumably some improvements to paste safety?
xterm notoriously hard to parse changelog, improvements to paste safety (disallowedPasteControls), fonts, clipboard improvements?

After writing those articles, bizarrely, I was still using rxvt even though it did not come up as shiny as I would have liked. The colors problems were especially irritating.

I briefly played around with Konsole and xterm, and eventually switched to XTerm as my default x-terminal-emulator "alternative" in my Debian system, while writing this.

I quickly noticed why I had stopped using it: clickable links are a huge limitation. I ended up adding keybindings to open URLs in a command. There's another keybinding to dump the history into a command. Neither are as satisfactory as just clicking a damn link.

Requirements

Figuring out my requirements is actually a pretty hard thing to do. In my last reviews, I just tried a bunch of stuff and collected everything, but a lot of things (like tab support) I don't actually care about. So here's a set of things I actually do care about:

Latency is particularly something I wonder about in Wayland. Kitty seem to have been pretty dilligent at doing latency tests, claiming 35ms with a hardware-based latency tester and 7ms with typometer, but it's unclear how those would come up in Wayland because, as far as I know, typometer does not support Wayland.

Candidates

Those are the projects I am considering.

Candidates not considered

Alacritty

I would really, really like to use Alacritty, but it's still not packaged in Debian, and they haven't fully addressed the latency issues although, to be fair, maybe it's just an impossible task. Once it's packaged in Debian, maybe I'll reconsider.

Kitty

Kitty is a "fast, feature-rich, GPU based", with ligatures, emojis, hyperlinks, pluggable, scriptable, tabs, layouts, history, file transfer over SSH, its own graphics system, and probably much more I'm forgetting. It's packaged in Debian.

So I immediately got two people commenting (on IRC) that they use Kitty and are pretty happy with it. I've been hesitant in directly talking about Kitty publicly, but since it's likely there will be a pile-up of similar comments, I'll just say why it's not the first in my list, even if it might, considering it's packaged in Debian and otherwise checks all the boxes.

I don't trust the Kitty code. Kitty was written by the same author as Calibre, which has a horrible security history and generally really messy source code. I have tried to do LTS work on Calibre, and have mostly given up on the idea of making that program secure in any way. See calibre for the details on that.

Now it's possible Kitty is different: it's quite likely the author has gotten some experience writing (and maintaining for so long!) Calibre over the years. But I would be more optimistic if the author's reaction to the security issues were more open and proactive.

I've also seen the same reaction play out on Kitty's side of things. As anyone who worked on writing or playing with non-XTerm terminal emulators, it's quite a struggle to make something (bug-for-bug) compatible with everything out there. And Kitty is in that uncomfortable place right now where it diverges from the canon and needs its own entry in the ncurses database. I don't remember the specifics, but the author also managed to get into fights with those people as well, which I don't feel is reassuring for the project going forward.

If security and compatibility wasn't such big of a deal for me, I wouldn't mind so much, but I'll need a lot of convincing before I consider Kitty more seriously at this point.

Next steps

It seems like Arch Linux defaults to foot in Sway, and I keep seeing it everywhere, so it is probably my next thing to try, if/when I switch to Wayland.

One major problem with foot is that it's yet another terminfo entry. They did make it into ncurses (patch 2021-07-31) but only after Debian bullseye stable was released. So expect some weird compatibility issues when connecting to any other system that is older or the same as stable (!).

One question mark with all Wayland terminals, and Foot in particular, is how much latency they introduce in the rendering pipeline. The foot performance and benchmarks look excellent, but do not include latency benchmarks.

No conclusion

So I guess that's all I've got so far, I may try alacritty if it hits Debian, or foot if I switch to Wayland, but for now I'm hacking in xterm still. Happy to hear ideas in the comments.

Stay tuned for more happy days.

Alacritty in Debian

Hi there! Really neat article. (I found it through the Planet Debian RSS feed.) I'm personally using Alacritty on Bullseye, and it's been great. I agree that having it packaged in Debian would be sweet, but until then, building it and installing it is pretty well documented on their github. You likely know this already, but I'll add the link for interested readers:

https://github.com/alacritty/alacritty/blob/master/INSTALL.md#manual-installation

Comment by Dan
comment 1
Just this week I’ve done a tentative play with Sway (and got Foot by default as a result) and I’ve been very pleased with both. I haven’t measured latency in any rigorous way but my immediate impression was one of extreme snappy ness.
Comment by Jonathan Dowland
Konsole

Unfortunately, the Konsole changelog is outdated. Much has happened over the last two years. See for example the 22.04 release announcement: https://kde.org/announcements/gear/22.04.0/

Also, from my experience, Konsole just works under wayland, and click-on-links has gotten better, preview image features

Comment by Sune
foot didn't work for me

After having used xterm for years, I've tried foot on Debian bookworm for a month. There were two annoyances that made me change back in the end:

  • There seems to be a compatibility issue between bash, readline and foot (with foot-terminfo installed). Occasionally, moving the cursor around would have it end up in a wrong spot. For reproducing, try using ctrl-a and a long line on the bottom of the screen.
  • I like xterm colors and the strong contrast used by default. Attempting to replicate the boring xterm colors on foot is not easy. No matter how many I configured, some colors would always be "weak". This is a problem when using a laptop in bad light conditions.
Comment by Helmut Grohne
foot initially didn't work for me

Original comment:

After having used xterm for years, I've tried foot on Debian bookworm for a month. There were two annoyances that made me change back in the end:

  • There seems to be a compatibility issue between bash, readline and foot (with foot-terminfo installed). Occasionally, moving the cursor around would have it end up in a wrong spot. For reproducing, try using ctrl-a and a long line on the bottom of the screen.
  • I like xterm colors and the strong contrast used by default. Attempting to replicate the boring xterm colors on foot is not easy. No matter how many I configured, some colors would always be "weak". This is a problem when using a laptop in bad light conditions.

It turns out that things aren't that simple and that the #foot IRC channel on irc.libera.chat is awesomely helpful, which includes the main author of foot. So let me debunk my own comment:

  • The compatibility issue is now present on xterm as well. That rules out foot as the cause.
  • Color is not color. xterm is limited to 16 colors by default unless you use xterm-256color. I've been using the 16 color variant. Those fewer colors are easier to tell apart obviously. foot provides many more colors and applications such as vim automatically use that support. The way to get good contrast in vim is to use a color scheme that has good contrast. The other piece where colors weren't similar is ls. It turns out that dircolors does not yet support foot. The foot wiki has a workaround for this situation.

So what looked like issues with foot was issues with lots of other components integrating differently for different terminal emulators.

Comment by Helmut Grohne
Created . Edited .