Looking at Wayland terminal emulators
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.
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
- resource usage
- proper clipboard support, that is:
- mouse selection and middle button uses PRIMARY
- control-shift-c and control-shift-v for CLIPBOARD
- true color support
- no known security issues
- active project
- paste protection
- clickable URLs
- scrollback
- font resize
- non-destructive text-wrapping (ie. resizing a window doesn't drop scrollback history)
- proper unicode support (at least latin-1, ideally "everything")
- good emoji support (at least showing them, ideally "nicely"), which involves font fallback
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.
- darktile - GPU rendering, Unicode support, themable, ligatures (optional), Sixel, window transparency, clickable URLs, true color support, not in Debian
- foot - Wayland only, daemon-mode, sixel images, scrollback search, true color, font resize, URLs not clickable, but keyboard-driven selection, proper clipboard support, in Debian
- havoc - minimal, scrollback, configurable keybindings, not in Debian
- sakura - libvte, Wayland support, tabs, no menu bar, original libvte gangster, dynamic font size, probably supports Wayland, in Debian
- termonad - Haskell? in Debian
- wez - Rust, Wayland, multiplexer, ligatures, scrollback search, clipboard support, bracketed paste, panes, tabs, serial port support, Sixel, Kitty, iTerm graphics, built-in SSH client (!?), not in Debian
- XTerm - status quo, no Wayland port obviously
- zutty: OpenGL rendering, true color, clipboard support, small codebase, no Wayland support, crashes on bremner's, in Debian
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 (!). Thankfully, there is a foot-terminfo
package that is available starting from Debian bullseye.
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.
Update: a few months after this article was written, I did switch a laptop to Wayland, and as part of that migration, adopted foot. It's great, and latency is barely noticeable. I recommend people try it out when they switch to Wayland, and, inversely, try out Wayland if only to try out Foot, it's a great terminal emulator.
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
Hi
It seems your link for Konsole changelog is currently unmaintained. It is missing many https://kde.org/announcements/releases/2020-12-apps-update/ many https://kde.org/announcements/gear/21.08.0/ many https://kde.org/announcements/gear/21.12.0/ many https://kde.org/announcements/gear/22.04.0/ changes
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
After having used
xterm
for years, I've triedfoot
on Debian bookworm for a month. There were two annoyances that made me change back in the end:bash
,readline
andfoot
(withfoot-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.xterm
colors and the strong contrast used by default. Attempting to replicate the boringxterm
colors onfoot
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.Original comment:
It turns out that things aren't that simple and that the
#foot
IRC channel onirc.libera.chat
is awesomely helpful, which includes the main author offoot
. So let me debunk my own comment:xterm
as well. That rules outfoot
as the cause.xterm
is limited to 16 colors by default unless you usexterm-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 asvim
automatically use that support. The way to get good contrast invim
is to use a color scheme that has good contrast. The other piece where colors weren't similar isls
. It turns out thatdircolors
does not yet supportfoot
. Thefoot
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.
Sorry, but no, I won't look at Terminology. I am actually surprised it still exists at all. When I last looked at it, it would just crash when opening a tab. And while this was fixed, nowadays I'm less into shiny bells and whistles things like what the Enlightenment project provides. I want stable software that does its job well, is configurable with a simple config file I can check into git, with reasonable keybindings.
Foot does all this, and just works, generally. The maintainer is friendly and already took some of my patches. I'm not going to review the dozens of other terminal emulators out there again...
Sorry!