Hi Laslo Thanks for giving this a shot!
A comment below. Laslo Hunhold <d...@frign.de> wrote: > Dear fellow hackers, > > this patch will hopefully resolve the many mails we get on dev@ and > hackers@ regarding crashes of st due to emoji-fonts triggering some > voodoo-condition in Xft. > > I hope my port of Anselm's change to dwm to st is correct and would > love to hear feedback. > > With best regards > > Laslo Hunhold > > [...] > > diff --git a/x.c b/x.c > index 5828a3b..074df47 100644 > --- a/x.c > +++ b/x.c > @@ -837,12 +837,24 @@ xgeommasktogravity(int mask) > int > xloadfont(Font *f, FcPattern *pattern) > { > + FcBool iscol; > FcPattern *configured; > FcPattern *match; > FcResult result; > XGlyphInfo extents; > int wantattr, haveattr; > > + /* Do not allow using color fonts. This is a workaround for a > BadLength > + * error from Xft with color glyphs. Modelled on the Xterm > workaround. See > + * https://bugzilla.redhat.com/show_bug.cgi?id=1498269 > + * https://lists.suckless.org/dev/1701/30932.html > + * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916349 > + * and lots more all over the internet. > + */ > + if(FcPatternGetBool(pattern, FC_COLOR, 0, &iscol) == FcResultMatch && > iscol) { > + return 1; > + } > + From what I can tell, returning 1 in this case won't work because st calls die() when xloadfont returns non-0 at all call sites. We would have to load a fallback font instead, I think. The dwm patch for for this issue [0] also adds this call to choose the fallback font. + FcPatternAddBool(fcpattern, FC_COLOR, FcFalse); We probably have to do the same in st. Cheers, Silvan [0] https://git.suckless.org/libsl/commit/53ebcb48c6b12882c6dbe352ee43c96b2fb01b84.html