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: Tue, 30 May 2023 15:10:45 +0300 Message-ID: <83ttvuf29m.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> <83ilcbgrxo.fsf@gnu.org> <87zg5nb3m3.fsf@gmail.com> <83bki3gpai.fsf@gnu.org> <87sfbfazfp.fsf@gmail.com> <837csrgioe.fsf@gnu.org> <87jzwqb7r3.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="10993"; 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 Tue May 30 14:11:26 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 1q3yCD-0002iu-Ot for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 May 2023 14:11:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3yBv-0001TO-Uj; Tue, 30 May 2023 08:11:07 -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 1q3yBq-0001S4-Hc for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 08:11: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 1q3yBq-0005Ch-6O for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 08:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q3yBp-0004qK-Hq for bug-gnu-emacs@gnu.org; Tue, 30 May 2023 08:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 May 2023 12:11:01 +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.168544861518553 (code B ref 63731); Tue, 30 May 2023 12:11:01 +0000 Original-Received: (at 63731) by debbugs.gnu.org; 30 May 2023 12:10:15 +0000 Original-Received: from localhost ([127.0.0.1]:60347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3yB5-0004pB-CF for submit@debbugs.gnu.org; Tue, 30 May 2023 08:10:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3yB0-0004op-UZ for 63731@debbugs.gnu.org; Tue, 30 May 2023 08:10:13 -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 1q3yAv-0004vi-Bc; Tue, 30 May 2023 08:10:05 -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=AAVHPZy5cQbVpRNZDTSUSsVwUO/P2f7AT7tyREuBp4c=; b=QiI5pt+KHj62hpBh1fPk PQySy9sRcuIFaOXB70oXhdwonSk96tRKIQtnEN1A1b9eeAiMGXZUbelovjFZvLv4W6FG3t+9DA3au wqAUDNoU7i+RT2Ca+d8Q4NcAk4SeJUg9MuQTd0xak2Egh4nfgDHdSGSK2fQFUsw+kfmSbXyLUDTBf 94sRIeeF1zYTABT12JRuCAZTNG3aWSyX9s4lEwZPlbzfWfl5YRfKH+bzNJP1PU+uUQz6k6PrB04C+ op2Jnhsvv1sqv+6/1yP9+LAPjjQh0wwipaMSqw7QrxyHVp1ycahL0wY9TxpbE0CCuxnsSVtnitFGw q5JsenHETo9vvQ==; 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 1q3yAu-0002w7-Qy; Tue, 30 May 2023 08:10:05 -0400 In-Reply-To: <87jzwqb7r3.fsf@gmail.com> (message from Robert Pluim on Tue, 30 May 2023 09:25:52 +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:262630 Archived-At: > From: Robert Pluim > Cc: 63731@debbugs.gnu.org, steven@stebalien.com > Date: Tue, 30 May 2023 09:25:52 +0200 > > >>>>> On Mon, 29 May 2023 20:18:41 +0300, Eli Zaretskii said: > > Eli> (set-char-table-range > Eli> composition-function-table > Eli> #xFE0F > Eli> '(["\\c.\ufe0f" 1 font-shape-gstring])) > >> > Eli> so that we only see a composition if the font indeed agrees to > Eli> compose. What do you see? > >> > >> It still displays a single glyph with a thin-space. If I customize > >> `glyphless-char-display-control' to display hex codes for VS, then it > >> display a hex box. > >> > >> So I guess that means weʼre not composing? > > Eli> What does "C-u C-x =" say in this case? > > It claims itʼs composed: > > position: 146 of 251 (58%), column: 0 > character: 👍 (displayed as 👍) (codepoint 128077, #o372115, #x1f44d) > charset: unicode (Unicode (ISO10646)) > code point in charset: 0x1F44D > script: emoji > syntax: w which means: word > category: .:Base > to input: type "C-x 8 RET 1f44d" or "C-x 8 RET THUMBS UP SIGN" > buffer code: #xF0 #x9F #x91 #x8D > file code: #xF0 #x9F #x91 #x8D (encoded by coding system utf-8-unix) > display: composed to form "👍️" (see below) > > Composed with the following character(s) "️" using this font: > ftcrhb:-GOOG-Noto Color Emoji-regular-normal-normal-*-13-*-*-*-m-0-iso10646-1 > by these glyphs: > [0 1 128077 569 16 0 17 13 4 nil] > with these character(s): > ️ (#xfe0f) VARIATION SELECTOR-16 Which means it _is_ composed. Moreover, with Noto Color Emoji we get a single glyph. On my system, I have Noto Emoji, from which I get two glyphs: [0 1 128077 422 17 1 15 12 2 nil] [0 1 65039 3 17 0 1 0 1 [0 0 0]] (in which case I can understand why the second one is displayed as a hex box if I customize glyphless-char-display-control). So, given that this is the case, why is this wrong, again? If the font and the shaper produce two glyphs, or one glyph that looks like two, why should we think it's an Emacs's problem? (I verified that Emacs 28 shows the same, so this is not a recent regression.)