bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54562: 28.0.91; Emoji sequence not composed


From: Eli Zaretskii
Subject: bug#54562: 28.0.91; Emoji sequence not composed
Date: Mon, 28 Mar 2022 14:51:49 +0300

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  54562@debbugs.gnu.org,  Eli
>  Zaretskii <eliz@gnu.org>
> Date: Mon, 28 Mar 2022 09:47:54 +0200
> 
> OK. So it sounds like we should perhaps look at doing composition for
> the codepoints in that block by doing face lookup based on the
> combining character rather than the base character.

I guess we should try.  It should be optional behavior, because Emacs
never did that, and I cannot predict what will that do to all the
different use cases where we compose text, and thus whether users will
like that in all the cases.  It could, for example, mean that a
particular Latin character with a diacritic will be displayed with a
font that's different from the rest of the Latin text, which some
users might consider worse than seeing just the base character in the
"expected" font.  And that's just the simplest use case.

And I think "based on combining character" is not the correct
definition.  We should allow selection of the font based on the
character that triggered the composition, i.e. the character whose
slot in composition-function-table stores the rule which we are using
to produce the composition.  Like we already do for Emoji.  For
combining characters, the default is that the combining character is
that trigger.  By contrast, today we use the font for the first
character in the composition sequence (NOT the base character, as I
incorrectly wrote earlier, although in practice it is the same for
Latin).

> Eli, should we look at doing that for other combining characters,
> such as Andreas' 0308?

"Look at" in what sense?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]