bug#39799: 28.0.50; Most emoji sequences don’t render correctly

[Eli Zaretskii]

> From: Mike FABIAN <mfabian@redhat.com>
> Cc: rpluim@gmail.com,  39799@debbugs.gnu.org
> Date: Sat, 29 Feb 2020 12:14:28 +0100
> 
> > IOW, what we need is a detailed description of what Pango does here,
> > and how does Gedit affect that by configuring its default fonts.  Only
> > then we can reason about the differences between that and what Emacs
> > does.
> 
> Yes, you are right, and I think this is very difficult.
> 
> I don’t know the details, but Pango seems to “cut” text into “runs”
> where each “run” is rendered with a single font. And it tries to
> cut the text into “runs” in a way that the overall result looks
> as nice as possible.

Every text-shaping engine, including those used by Emacs, does that.
The devil is in the details: how exactly are the "runs" decided.

> >> Yes, it does tell that it was composed with the following character:
> >
> > And the resulting display is what you expect?  If not, then I think
> > you need to find a font which supports Emoji presentation of
> > characters such as Ⓜ, and make Emacs use it for those sequences.
> 
> Yes, in the case of Ⓜ️ U+24C2 U+FE0F the result in Emacs is perfect
> when using “Noto Color Emoji” or “Joypixels”. It is displayed in colour
> and behaves as a single character in the buffer, the variation selector
> is not displayed as a box. This is perfect.
> 
> But when using Symbola for the same sequence one sees U+FE0F as an ugly
> box.

So we should augment our default fontsets to use Emoji-capable fonts
in preference to those, like Symbola, which aren't.  And perhaps for
Emoji we should make the exception in the rule that we prefer the
default face's font, so that users will not need to tweak
use-default-font-for-symbols to have Emoji display with those capable
fonts.  Patches to these effects are welcome.

> But what about # U+0023 NUMBER SIGN ?
> 
> This does have an emoji representation.

The question is how important is to be able to display that character
as an Emoji, in the context of the jobs that Emacs is mainly used
for.  Maybe not too much.

> How could this ever work in Emacs? If you have to decide for a single
> font to render U+0023 in Emacs, you would need to set a “capable” emoji
> font for an ASCII character like #. One probably does not want to do
> that.

If fonts like DejaVu Sans Mono and others, routinely used for
displaying fixed-pitch text (such as program source code) acquire the
capabilities of displaying Emoji, that is exactly what should be done.
As long as the current tendency of using Emoji everywhere continues, I
see no reason not to expect those fonts to be enhanced to support
Emoji.

> Then # in text representation would look different in style than
> the other ASCII characters because it would come as the text
> representation glyph from some emoji font which would probably not go
> well together with other ASCII characters coming from some font like
> for example “DejaVu Sans Mono”. So one probably wants to set
> something like “DejaVu Sans Mono” for # as well, otherwise normal text
> won’t look nice. But how can one display U+0023 U+FE0F as am emoji then?
> 
> This seems very messy, I don’t know how this can be solved.

The 'face' text property method I mentioned elsewhere should still
work, even if a single font cannot display both text and Emoji
presentation of the sequences.