bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs

[Eli Zaretskii]

> Date: Thu, 10 Feb 2022 15:34:05 -0800
> From: "Greg A. Woods" <woods@robohack.ca>
> CC: 53924@debbugs.gnu.org
> 
> Yes, indeed I do consider it a problem -- something is sometimes
> swapping glyphs that should not be doing so, and doing so inconsistently
> for some reason.

It might look inconsistent from your POV, but Emacs has its own ideas
about this, and they are consistent as soon as one understands the
code and its design ideas.

> I don't consider all the fonts available to be "good enough for Emacs",
> quite the contrary, but I do believe Emacs should be able to show me
> text rendered with any and all available glyphs from these fonts upon
> request.  If Xterm can, why can't Emacs?

Emacs is not xterm.  Emacs doesn't examine each and every glyph of a
font when it decides when to use it, because that would be
prohibitively expensive on systems that have many fonts available.
AFAIK, xterm uses a static arrangement of fonts, and does not by
itself look for fonts suitable for a given character outside of the
set of fonts specified to it externally.  Well, that's not how Emacs
works, not at all.  So there's little surprise the results might be
different for some fonts.

> The exception of course is if there's something actually wrong with the
> font, or its encoding, or some such non-Emacs problem.  I would expect
> such problems to show up in xfontsel though.

How can xfontsel know which problems are relevant to Emacs use of
fonts and Emacs display engine in general?

> One more possibly relevant observation:  I don't see this problem with
> Emacs built using the "nextstep" toolkit and running on native macOS.
> There even when the font has a strange encoding (e.g. for symbol fonts),
> or no ASCII glyphs at all, I see either the symbols in their place, or
> empty boxes.

So maybe what you see is specific to that OS (NetBSD, AFAIU).

FWIW, I don't see what we can do about this bug report.