GNU bug report logs - #63731
[PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

Previous Next

Full log

Message #122 received at 63731 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: Re: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F)
 where appropriate
Date: Thu, 01 Jun 2023 18:34:53 +0200

>>>>> On Thu, 01 Jun 2023 19:10:16 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
    >> Date: Thu, 01 Jun 2023 15:30:18 +0200
    >> 
    Eli> OK, the issue is quite clear even without stepping with a debugger.
    >> 
    Eli> Bottom line: we cannot support a situation where the same character
    Eli> can be composed by more than one slot in composition-function-table.
    Eli> If there are more than a single slot for the same character, one of
    Eli> them will be tried, and the rest will be ignored (not even tried).
    Eli> In particular, if a character CH has a "forward" composition rule that
    Eli> starts with itself, and also has a "backward" rule (one with non-zero
    Eli> look-back parameter) triggered by a different character (which should
    Eli> follow CH), the latter rule will never be tried.
    >> 
    >> OK, that makes sense. Where would be a good place to document this?

    Eli> In the doc string of composition-function-table, I think.  We already
    Eli> document there the caveat of arranging rules in descending order of
    Eli> look-back, which is part of the same "misfeature".

OK. Iʼll see if I can come up with something (or Iʼll just steal what
you wrote above :-)).

    >> That makes all the VS-16 sequences in
    >> admin/unidata/emoji-variation-sequences.txt display with the emoji
    >> font for me.

    Eli> Ready to install this on the emacs-29 branch?

Not today. My brain is fuzzy, and it needs more testing (the patch,
not my brain).

    >> If find-composition DTRT, could we not use it in the display engine?

    Eli> Not easily, because the display code calls subroutines of
    Eli> find-composition in a certain order, and that's what causes the
    Eli> behavior I described.

    Eli> And even if we could make this happen, I'm not sure we should:
    Eli> basically, having multiple matching slots would mean users and callers
    Eli> will never be sure which one "wins".

Yes, at least the semantics are clear (now that we know what they
are).

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.