bug#54562: 28.0.91; Emoji sequence not composed

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: luangruo@yahoo.com,  larsi@gnus.org,  54562@debbugs.gnu.org
> Date: Mon, 28 Mar 2022 14:46:09 +0200
> 
>     Eli> I guess we should try.  It should be optional behavior, because Emacs
>     Eli> never did that, and I cannot predict what will that do to all the
>     Eli> different use cases where we compose text, and thus whether users 
> will
>     Eli> like that in all the cases.  It could, for example, mean that a
>     Eli> particular Latin character with a diacritic will be displayed with a
>     Eli> font that's different from the rest of the Latin text, which some
>     Eli> users might consider worse than seeing just the base character in the
>     Eli> "expected" font.  And that's just the simplest use case.
> 
> Yes, thatʼs exactly what happens with U+0308 here sometimes, see
> screenshot below. I had to search a bit to find a font to use as the
> default that didnʼt have a glyph for U+0308, so Iʼm not sure how
> important this issue is in practice.

I wasn't talking specifically about U+0308, I was talking about
combining diacritics in general.  Some newer ones could be missing
from fonts that otherwise cover Latin character sets.

>     Eli> "Look at" in what sense?
> 
> 'consider'
> 
> Rough patch attached. It does U+20E3, U+0308, and U+20D0..U+20FF. It
> works kind of ok, but U+006F U+0308 suffers from the font problem you
> were worried about. With Bitstream Vera Mono, the composed glyph ends
> up being from Latin Modern Roman, which looks very different.
> 
> The composed glyphs for U+20D0..U+20FF look pretty bad in all the
> fonts Iʼve tried so far: Unifont, FreeSans, Free Mono, Menlo,
> Bitstream Vera Mono. Does anyone have an idea of a good font for
> those?

I'll let people comment on whether this is worth an optional
behavior.

> +static bool
> +codepoint_is_combining_lookup_eligible (int ch)
> +{
> +  if ((0x20D0 <= ch && ch <= 0x20FF) || ch == 0x308)
> +    return true;
> +  return false;
> +}

Any reason not to use the Unicode category here?  Or do we want to
support only specific characters (in which case U+0308 is still not
the only one)?