Some time ago I switched to AwesomeWM and with that came another change, my default terminal emulator. Having used GNOME terminal for years, I soon switched to Terminator back in the day. Leaving GNOME behind, in search for a more lean desktop with less frills and more keyboard centric features, I also had to ditch that terminal emulator (it has too many dependencies for my use case). Eventually I stumbled upon st, which fit the bill.
st still seems almost perfect for me and I'm sticking with it, for now. There is one annoying bug though, which came to light when I started receiving e-mails with emoticons. Those emoticons crashed my 'st' instance!
This is actually caused by an upstream Xft bug. When emoticons are displayed, they crash st. I had to resort to using xterm sometimes, which is, well, not a great experience nowadays. I set out on a journey to fix my desktop.
So I checked the FAQ of st and found an answer to my issue:
## BadLength X error in Xft when trying to render emoji Xft makes st crash when rendering color emojis with the following error: "X Error of failed request: BadLength (poly request too large or internal Xlib length error)" Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 20 (RenderAddGlyphs) Serial number of failed request: 1595 Current serial number in output stream: 1818" This is a known bug in Xft (not st) which happens on some platforms and combination of particular fonts and fontconfig settings. See also: https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6 https://bugs.freedesktop.org/show_bug.cgi?id=107534 https://bugzilla.redhat.com/show_bug.cgi?id=1498269 The solution is to remove color emoji fonts or disable this in the fontconfig XML configuration. As an ugly workaround (which may work only on newer fontconfig versions (FC_COLOR)), the following code can be used to mask color fonts: FcPatternAddBool(fcpattern, FC_COLOR, FcFalse); Please don't bother reporting this bug to st, but notify the upstream Xft developers about fixing this bug.
Waiting for the patch to be finalized in xft, then released and then used in my Desktop distibution of choice (currently Ubuntu 20.04) will take too long (yes, I am impatient). So, I decided to patch libxft2 manually on my system, using the patch by Maxime (thank you Maxime!). I also created my own patch file, since I had merge errors. Here are the instructions:
apt-get source libxft2 patch -p0 < modified_for_ubuntu_20.04.1.patch debuild -b -uc -us sudo dpkg -i ../libxft2_2.3.3-0ubuntu1_amd64.deb