From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate Date: Mon, 29 May 2023 16:58:43 +0300 Message-ID: <83ilcbgrxo.fsf@gnu.org> References: <87a5xrzsph.fsf@stebalien.com> <83pm6nlhll.fsf@gnu.org> <87v8gfmqyt.fsf@gmail.com> <83ilcflbua.fsf@gnu.org> <87mt1rmjjg.fsf@gmail.com> <83v8gfjnzj.fsf@gnu.org> <87edn3mbr3.fsf@gmail.com> <83mt1rjg69.fsf@gnu.org> <875y8fm7x7.fsf@gmail.com> <83lehbjdjd.fsf@gnu.org> <87wn0vkqn1.fsf@gmail.com> <83jzwvj94x.fsf@gnu.org> <87h6rw8y82.fsf@gmail.com> <83353gipww.fsf@gnu.org> <87edmzto0l.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3632"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63731@debbugs.gnu.org, steven@stebalien.com To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 29 15:59:38 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q3dPM-0000gH-NN for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 May 2023 15:59:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3dOw-0002Ek-Ek; Mon, 29 May 2023 09:59:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q3dOp-0002Dw-5d for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 09:59:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q3dOo-0004QS-SP for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 09:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q3dOo-0008OK-Nq for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 09:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 May 2023 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63731 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 63731-submit@debbugs.gnu.org id=B63731.168536869632181 (code B ref 63731); Mon, 29 May 2023 13:59:02 +0000 Original-Received: (at 63731) by debbugs.gnu.org; 29 May 2023 13:58:16 +0000 Original-Received: from localhost ([127.0.0.1]:58646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3dO3-0008Mz-F0 for submit@debbugs.gnu.org; Mon, 29 May 2023 09:58:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3dNy-0008MU-5u for 63731@debbugs.gnu.org; Mon, 29 May 2023 09:58:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q3dNs-0003d2-Mt; Mon, 29 May 2023 09:58:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=O5RcW6xnRVRqastIc96AUjNtOFqTSioySbS1yLHzDY0=; b=HyAK2jaDXOgDRyL70ZDP YMzNtoEDk8e/7v04yzwnW/MPXl/S9l2HvVTN+zYtERuLs5XUp8kEjcynEZvIEXs4MZvRfMB6k4CuS iF7QyYUeO6ZMmB078qlMRHubgxNmEWomXC2dvS8FvIOdSKrTNT4arDOMpBJDBTCbCKH7IzNppRS1x idWOPWgFR6ifcD1LLqPk6YV0ISDgLyx+fXGelxw4TUQLEM4EjC6b4hZxZssl4gB8ZVQHeRXiRwlJA diXgm/v/mNsaZ+pYfMPT+yZT8DYUHLXfXr2B91z+xqrWvAP5OpgdElWDwInev1mYeeZUEdU2bqAay BP4g6EHKDv1rNg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q3dNs-0005Ro-61; Mon, 29 May 2023 09:58:04 -0400 In-Reply-To: <87edmzto0l.fsf@gmail.com> (message from Robert Pluim on Mon, 29 May 2023 12:44:58 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262577 Archived-At: > From: Robert Pluim > Cc: 63731@debbugs.gnu.org, steven@stebalien.com > Date: Mon, 29 May 2023 12:44:58 +0200 > > In all these cases, consider the sequence U+1F44D U+FE0F > > - emacs-29: > > Displays as colour emoji, followed by an empty box > > - emacs-29 with the following change in composite.el: > > (set-char-table-range > composition-function-table > #xFE0F > `([,(purecopy "\\c.\ufe0f") 1 compose-gstring-for-graphic])) > > Displays as colour emoji. Much rejoicing. If I follow my own > advice, and customize `glyphless-char-display-control' to show > hex-boxes for variation selectors, you then see that in actual > fact, we are still displaying the FE0F, but since it uses > thin-space by default, it wasnʼt obvious. Much sadness. > > C-u C-x =: > > display: composed to form "👍️" (see below) This is not what I see. I didn't use the above set-char-table-range expression literally, but instead started "emacs -Q", and then evaluated in *scratch*: (set-char-table-range composition-function-table #xFE0F '(["\\c.\ufe0f" 1 compose-gstring-for-graphic])) After that, the sequence U+1F44D U+FE0F displays as a single glyph, and there's no thin space after it. What am I missing? Is this somehow specific to ftcrhb font driver or something? > Now I notice (via emoji-variation-sequences.txt), that this is only > happening for the following codepoints. > > U+1F408 > U+1F415 > U+1F426 > U+1F446 > U+1F447 > U+1F448 > U+1F449 > U+1F44D > U+1F44E > > And if I look in lisp/international/emoji-zwj.el, I find: > > (#x1F44D . > ,(eval-when-compile (regexp-opt > '( > "\N{U+1F44D}\N{U+1F3FB}" > "\N{U+1F44D}\N{U+1F3FC}" > "\N{U+1F44D}\N{U+1F3FD}" > "\N{U+1F44D}\N{U+1F3FE}" > "\N{U+1F44D}\N{U+1F3FF}" > )))) > > If I add > > "\N{U+1F44D}\N{U+FE0F}" > > to that, and undo the composite.el change, then everything is > fine. Hurrah! This means that the > > `([,(purecopy "\\c.\\c^+") 1 compose-gstring-for-graphic] > [nil 0 compose-gstring-for-graphic]) > > is not doing the right thing for this case. You are saying that the entry in composition-function-table for U+1F44D (and other similar characters) is used in preference to the entry for U+FE0F that follows it, even though there's no U+1F3FB etc. after it to "steal" the composition? Did you try stepping through composite.c to see whether and why this is the case? > I can change the emoji-zwj.awk script to add CHAR+FE0F for all emoji, > unless someone knows how to fix composition to do the right thing > here. I think we need first to understand the issue at hand better. There's more here than meets the eye, I think.