bug#43177: Bug: Emacs 27.1 hangs forever in `FcCharSetSubtractCount' from '/usr/lib/libfontconfig.so.1'

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  43177@debbugs.gnu.org,
>   emacs@Alexander.Shukaev.name
> Date: Fri, 04 Sep 2020 09:45:37 +0200
> 
>     >> My guess would be that probing fonts via the x backend is expensive due
>     >> to round trips to the X server (and the X server is quite busy during
>     >> that time).
> 
>     Eli> If that is the reason, I guess we should try to minimize the number of
>     Eli> fonts for which this is done.  Like, for example, set up some data
>     Eli> structure to be consulted when a deciding whether a given font should
>     Eli> be used with the x backend.  After all, the number of fonts for which
>     Eli> that backend is needed is quite small, basically bitmapped fonts.
> 
> xfont_supported_scripts already skips opening a font if itʼs for
> Japanese or Korean. Perhaps we should add tai-viet to that list?

I don't think this would help, because most scripts don't specify
language properties like 'ja' or 'ko', which is what
xfont_supported_scripts uses.

> Perhaps we should flip the default of scalable-fonts-allowed to nil
> under GNU/Linux? [1]
> (unless the only available font-backend is 'x', which can only happen
> if the user explicitly sets it that way)?

That'd be backward-incompatible.  Besides, I think it's too late.  I
think we should do this in font.c, where the 'list' method of each
font backend is called.  There, we should not call the 'x' backend
unless the no fonts were found by the backend called before it.  This
should be controlled by a variable exposed to Lisp, of course.

Does that make sense?