Subject: Re: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

From: Robert Pluim <[email-masked]>
Date: Fri, 26 May 2023 13:14:27 +0200

>>>>> On Fri, 26 May 2023 11:46:05 +0300, Eli Zaretskii <[email-masked]> said:

    >> From: Robert Pluim <[email-masked]>
    >> Cc: Steven Allen <[email-masked]>,  [email-masked]
    >> Date: Fri, 26 May 2023 10:34:02 +0200
    >> 
    >> Ugh. The following fixes it for me:
    >> 
    >> diff --git a/lisp/composite.el b/lisp/composite.el
    >> index fb8b76114f4..af86d1436d3 100644
    >> --- a/lisp/composite.el
    >> +++ b/lisp/composite.el
    >> @@ -756,7 +756,7 @@ compose-gstring-for-dotted-circle
    >> ;; Allow for bootstrapping without uni-*.el.
    >> (when unicode-category-table
    >> (let ((elt `([,(purecopy "\\c.\\c^+") 1 compose-gstring-for-graphic]
    >> -	       [nil 0 compose-gstring-for-graphic])))
    >> +	       )))

    Eli> This is unacceptable, AFAIU.  We cannot unsupported (or change) the
    Eli> correct display of mark characters, can we?

Right. Iʼll hold off pushing it 😃

    >> Although the following is less invasive:
    >> 
    >> diff --git a/lisp/composite.el b/lisp/composite.el
    >> index fb8b76114f4..333428f008a 100644
    >> --- a/lisp/composite.el
    >> +++ b/lisp/composite.el
    >> @@ -762,6 +762,11 @@ compose-gstring-for-dotted-circle
    >> (if (memq val '(Mn Mc Me))
    >> (set-char-table-range composition-function-table key elt)))
    >> unicode-category-table))
    >> +  ;; for Emoji presentation selector
    >> +  (set-char-table-range
    >> +   composition-function-table
    >> +   #xFE0F
    >> +    `([,(purecopy "\\c.\ufe0f") 1 compose-gstring-for-graphic]))
    >> ;; for dotted-circle
    >> (aset composition-function-table #x25CC
    >> `([,(purecopy ".\\c^") 0 compose-gstring-for-dotted-circle]))

    Eli> Can you please explain why the current setup doesn't work in this
    Eli> case, even though "C-u C-x =" says the composition was done?  And how
    Eli> the above patch fixes that?

Composition is done for 1f44d+fe0f, but I suspect that with the current
setup, composition is called again for FE0F, which results in the box
glyph. With the second patch we will only do backwards looking composition
for FE0F

    >> Didnʼt we conclude that composition had some issues with multiple
    >> entries for the same codepoint if there was a mix for forward and
    >> backward looking regexp?

    Eli> Not sure I understand to what does this allude.  What mix of forward
    Eli> and backward looking regexp do you see?

Youʼre right, thereʼs no forward looking regexp, only a backwards one
and a no-regexp. But itʼs undeniable that:

 [nil 0 compose-gstring-for-graphic]

causes the issue. Iʼve never been clear on the semantics of that.

Robert
--