Fontconfig never reports failure - with workable solution.

[Jemi]

So I emerged lemonbar-xft, and attempted to try out the last example on the arch linux lemonbar page:

https://wiki.archlinux.org/index.php/lemonbar#Font_Awesome_icons

Unfortunately, for some reason it's not working - the Font Awesome glyph won't display - and lemonbar-xft doesn't report failure or give me any information to help me debug this problem. Looking around the lemonbar-xft issues tracker, I found a link to this page, which explains why:

http://www.freedesktop.org/software/fontconfig/fontconfig-user.html

Fontconfig never fails to select a font, it always just selects a closest match. So fontconfig will never return an error if it can't give you the font you want. On the surface, this is pretty terrible behavior. Luckily, there's an easy fix. Every time lemonbar-xft loads a font, it should report the name of the font it loads on STDERR. Then, in sort of an inversion of the usual pattern on unix, not reporting anything on STDERR while attempting to load a font would ALWAYS indicate an error, whereas reporting something on STDERR while attempting to load a font COULD be an error (user error or program error) depending on whether the user got the font they want.

It might be a little weird, but I think this is the only real solution. Because failing to give the user their preferred font and also not giving them any sort of explanation at all is really unacceptable. The linked document seems to say that the environment variable FC_DEBUG controls this behavior, but unfortunately I can't seem to pass this variable to fontconfig via lemonbar-xft by way of the commandline. It seems like lemonbar-xft should set this to something sensible by default (like 1 or 2 perhaps), and also make it configurable with a verbosity switch, and also allow the internal variable to be set directly by passing a commandline variable.

[Jemi]

Ok, so lemonbar-xft evidently does give debug information when FC_DEBUG is set, but for some reason lemonbar-xft can't read that environment variable from within a pipeline. I'm not sure if this is a problem with lemonbar-xft or if my understanding of unix pipelines is off. In any case, the output produced with FC_DEBUG=1 is not really 'brief' as implied by the document, although it might be brief as font debugging output goes. So it seems like the FC_DEBUG behavior described in the document is not really appropriate for the needs of people trying to casually troubleshoot their issue when they don't get the output they expect. Instead, I think that when FC_DEBUG is 0 or unset, lemonbar-xft should output to STDERR, for each xft font that the user directed it to load, the actual xft font that it ends up loading.