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

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

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


From: Eli Zaretskii
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Fri, 28 Feb 2020 18:19:10 +0200

> From: Robert Pluim <address@hidden>
> Cc: Glenn Morris <address@hidden>,  address@hidden,  address@hidden
> Date: Fri, 28 Feb 2020 15:14:01 +0100
> 
>     >> It matches forward off the first char, so the
>     >> composition-function-table entries all have '0' as the number of chars
>     >> to match. Would it be better to match backwards?
> 
>     Eli> I don't think matching backwards is better in general.  Did you have 
> a
>     Eli> reason for thinking it was?
> 
> I thought I saw a comment in composite.c that says matching is done
> backward, but I see that itʼs done forwards as well.

Btw, it sometimes _can_ be beneficial to use backward matching: if it
makes the size of composition-function-table smaller.  Since
composition-function-table is a char-table, and char-tables allocate
sub-tables only if needed, you can conserve memory (and thus make
Emacs's memory footprint smaller) and faster (because 'aref' will llok
up values in a char-table faster) by setting a smaller number of
slots.  For example, if the 2nd character of an Emoji sequence was
always one specific character, or a small set of characters, you could
set only the slots of those few characters, which would make the
char-table smaller.  OTOH, if that would yield many different
composition rules in the list of rules for those few characters,
redisplay could become slower, because it generally examines the rules
one by one until it finds an appropriate one.  So the winning setup of
composition-function-table is the one that sets the smallest number of
slots, but still keeps the lists of rules for those slots short.  And
note that setting the same rule for a range of codepoints generally
uses up only one slot in the char-table, so rules that can be
generalized to cover many characters are preferable.





reply via email to

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