Re: [hackers] [slstatus] Follow International System of Units spacing rules
Hi Ingo, Following standards sounds like a good idea. I merged the patch. Cheers! Aaron -- Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/ GPG: 0x7A65E38D55BE96FE Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE
Re: [hackers] Re: [libsl][PATCH] Workaround Xft BadLength X error
(CCed reporter of Debian compile issue)
Excerpts from Hiltjo Posthuma's message of February 17, 2019 10:37 am:
> On Sun, Feb 17, 2019 at 09:13:04AM +, Thomas Spurden wrote:
>> Excerpts from Thomas Spurden's message of January 16, 2019 9:51 pm:
>> > Modify the fontconfig pattern to prefer non-color fonts, and discard any
>> > selected font which has the color flag set. Using these fonts with Xft is
>> > just
>> > going to generate a BadLength X error.
>>
>> I have received a report from a Debian user that dwm doesn't compile on
>> Debian
>> stable with this change. It appears Debian 9 has a version of fontconfig
>> (2.11.0) from before FC_COLOR was added (2.11.91).
>>
>> Surrounding the patched lines with #ifdef FC_COLOR would allow compilation
>> with
>> these older versions of fontconfig, but I assume will mean that the original
>> issue (Xft crashing dwm/dmenu) will recur on those systems.
>>
>> Is it preferred to:
>> a) fail to compile with the older versions of fontconfig (current behaviour)
>> b) compile but crash at runtime if a color font is selected for a character
>> ?
>>
>
> I've already seen this on Devuan/Debian stable.
>
> It's up to you how to handle this. There will be no more #ifdefs for this
> crap.
>
> I'm already not happy with this workaround and how the upstream developers
> handle this bug. It is very stupid each application has to implement this
> workaround now.
I agree that this is rubbish - it's only worth considering because of the
severity of the result (window title causes window manager to crash).
>
> Note that there may be more generic ways in Freetype to filter functionality
> like on color (when supported), prgname and other "filters".
I had a quick look and saw the FC_COLOR tag is based on a property of the
FT_Face flags, this appears to suffice (instead of my original patch):
--- a/drw.c
+++ b/drw.c
@@ -132,6 +132,14 @@ xfont_create(Drw *drw, const char *fontname, FcPattern
*fontpattern)
die("no font specified.");
}
+ FT_Face face = XftLockFace(xfont);
+ if(face->face_flags & FT_FACE_FLAG_COLOR) {
+ XftUnlockFace(xfont);
+ XftFontClose(drw->dpy, xfont);
+ return NULL;
+ }
+ XftUnlockFace(xfont);
+
font = ecalloc(1, sizeof(Fnt));
font->xfont = xfont;
font->pattern = pattern;
(Only had cursory testing)
I am happy with the original fix as I am on a distro with non-ancient
fontconfig. Anyone who wants to take the above and make a proper patch of it is
of course welcome to do so.
[hackers] [st][PATCH] config: add Ctrl-Tab, Shift-Ctrl-Tab Xterm escapes
Ctrl-Tab, Shift-Ctrl-Tab are common combinations to switch between tabs
or panes in applications. This adds their mapping into escape sequences
following definitions from Xterm.
---
config.def.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.def.h b/config.def.h
index 0e01717..aa2642b 100644
--- a/config.def.h
+++ b/config.def.h
@@ -322,6 +322,8 @@ static Key key[] = {
{ XK_Right, XK_ANY_MOD, "\033[C",0, -1},
{ XK_Right, XK_ANY_MOD, "\033OC",0, +1},
{ XK_ISO_Left_Tab, ShiftMask, "\033[Z",0,0},
+ { XK_Tab, ControlMask,"\033[27;5;9~", 0,0},
+ { XK_ISO_Left_Tab,ShiftMask|ControlMask,"\033[27;6;9~",0, 0},
{ XK_Return,Mod1Mask, "\033\r",0,0},
{ XK_Return,XK_ANY_MOD, "\r",0,0},
{ XK_Insert,ShiftMask, "\033[4l", -1,0},
--
2.20.1
Re: [hackers] Re: [libsl][PATCH] Workaround Xft BadLength X error
On Sun, Feb 17, 2019 at 09:13:04AM +, Thomas Spurden wrote:
> Excerpts from Thomas Spurden's message of January 16, 2019 9:51 pm:
> > Modify the fontconfig pattern to prefer non-color fonts, and discard any
> > selected font which has the color flag set. Using these fonts with Xft is
> > just
> > going to generate a BadLength X error.
>
> I have received a report from a Debian user that dwm doesn't compile on Debian
> stable with this change. It appears Debian 9 has a version of fontconfig
> (2.11.0) from before FC_COLOR was added (2.11.91).
>
> Surrounding the patched lines with #ifdef FC_COLOR would allow compilation
> with
> these older versions of fontconfig, but I assume will mean that the original
> issue (Xft crashing dwm/dmenu) will recur on those systems.
>
> Is it preferred to:
> a) fail to compile with the older versions of fontconfig (current behaviour)
> b) compile but crash at runtime if a color font is selected for a character
> ?
>
I've already seen this on Devuan/Debian stable.
It's up to you how to handle this. There will be no more #ifdefs for this crap.
I'm already not happy with this workaround and how the upstream developers
handle this bug. It is very stupid each application has to implement this
workaround now.
Note that there may be more generic ways in Freetype to filter functionality
like on color (when supported), prgname and other "filters".
> >
> > ---
> > drw.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > The internet has lots of reports of this, sounds like it might be a bug in
> > Xft?
> > Anyway, it's super annoying to have your window manager crash due to the
> > characters in the window title!
> >
> > This has been reported several times on the suckless lists e.g.
> > https://lists.suckless.org/dev/1610/30710.html
> > https://lists.suckless.org/dev/1608/30245.html
> >
> > Searching the internet for "Xft BadLength" pulls up lots of bugs in various
> > sofware packages which use Xft. Xterm implemented something similar to the
> > attached patch in version 314.
> >
> > There are several recommendations of just uninstalling the color fonts
> > (usually
> > seem to be the noto emoji font) e.g.
> > https://wiki.archlinux.org/index.php/dwm#Crashes_due_to_Emojis_in_some_fonts
> >
> > That just seems like a poor solution to me!
> >
> > For the record this error can be easily reproduced with
> >> echo -e '\xf0\x9f\x8e\xa5\x20\x56'|dmenu
> > (dmenu built from latest git with no modifications) assuming you have a
> > color
> > emoji font installed and fontconfig selects it. Have a look through the
> > output
> > of
> >> fc-match -s monospace
> > and see if you have 'Noto Color Emoji' in there (I have it second to last).
> >
> > diff --git a/drw.c b/drw.c
> > index c1582e7..8fd1ca4 100644
> > --- a/drw.c
> > +++ b/drw.c
> > @@ -132,6 +132,19 @@ xfont_create(Drw *drw, const char *fontname, FcPattern
> > *fontpattern)
> > die("no font specified.");
> > }
> >
> > + /* 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.
> > +*/
> > + FcBool iscol;
> > + if(FcPatternGetBool(xfont->pattern, FC_COLOR, 0, ) ==
> > FcResultMatch && iscol) {
> > + XftFontClose(drw->dpy, xfont);
> > + return NULL;
> > + }
> > +
> > font = ecalloc(1, sizeof(Fnt));
> > font->xfont = xfont;
> > font->pattern = pattern;
> > @@ -337,6 +350,7 @@ drw_text(Drw *drw, int x, int y, unsigned int w,
> > unsigned int h, unsigned int lp
> > fcpattern = FcPatternDuplicate(drw->fonts->pattern);
> > FcPatternAddCharSet(fcpattern, FC_CHARSET, fccharset);
> > FcPatternAddBool(fcpattern, FC_SCALABLE, FcTrue);
> > + FcPatternAddBool(fcpattern, FC_COLOR, FcFalse);
> >
> > FcConfigSubstitute(NULL, fcpattern, FcMatchPattern);
> > FcDefaultSubstitute(fcpattern);
> > --
> > 2.20.1
> >
> >
>
--
Kind regards,
Hiltjo
Re: [hackers] Re: [libsl][PATCH] Workaround Xft BadLength X error
On Sun, Feb 17, 2019, at 22:13, Thomas Spurden wrote: > Excerpts from Thomas Spurden's message of January 16, 2019 9:51 pm: > > Modify the fontconfig pattern to prefer non-color fonts, and discard any > > selected font which has the color flag set. Using these fonts with Xft is > > just > > going to generate a BadLength X error. > > I have received a report from a Debian user that dwm doesn't compile on Debian > stable with this change. It appears Debian 9 has a version of fontconfig > (2.11.0) from before FC_COLOR was added (2.11.91). Note that Fontconfig 2.11.0 was released in 2013: https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.11.0
