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#54562: 28.0.91; Emoji sequence not composed Date: Mon, 28 Mar 2022 16:12:06 +0300 Message-ID: <837d8e9q6x.fsf@gnu.org> References: <87bkxu8k7t.fsf.ref@yahoo.com> <87bkxu8k7t.fsf@yahoo.com> <83wngiba3j.fsf@gnu.org> <874k3m8grb.fsf@yahoo.com> <87pmmauwtp.fsf@gmail.com> <87y20y6ypi.fsf@yahoo.com> <83pmmab53s.fsf@gnu.org> <87sfr66sb7.fsf@yahoo.com> <87a6deunjj.fsf@gmail.com> <87k0ch5x8k.fsf@yahoo.com> <83h77lb6km.fsf@gnu.org> <871qyod5d5.fsf@gnus.org> <87zglc2q14.fsf@yahoo.com> <87y20vtor6.fsf@gmail.com> <87a6db2ajo.fsf@yahoo.com> <87mthatt5h.fsf@gmail.com> <838rsu9twq.fsf@gnu.org> <875ynytfce.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="27281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, larsi@gnus.org, 54562@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 28 15:30:10 2022 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 1nYpRh-0006uA-PW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Mar 2022 15:30:09 +0200 Original-Received: from localhost ([::1]:42072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYpRg-0004mP-M1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Mar 2022 09:30:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54034) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYpB9-000623-NY for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2022 09:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35396) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nYpB9-0004ha-9J for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2022 09:13:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nYpB9-00017k-54 for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2022 09:13:03 -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, 28 Mar 2022 13:13:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54562 X-GNU-PR-Package: emacs Original-Received: via spool by 54562-submit@debbugs.gnu.org id=B54562.16484731324226 (code B ref 54562); Mon, 28 Mar 2022 13:13:03 +0000 Original-Received: (at 54562) by debbugs.gnu.org; 28 Mar 2022 13:12:12 +0000 Original-Received: from localhost ([127.0.0.1]:57521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYpAJ-000166-V0 for submit@debbugs.gnu.org; Mon, 28 Mar 2022 09:12:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYpAI-00015s-5O for 54562@debbugs.gnu.org; Mon, 28 Mar 2022 09:12:10 -0400 Original-Received: from [2001:470:142:3::e] (port=35534 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYpAC-0004WI-T2; Mon, 28 Mar 2022 09:12: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=i0wXKbp1GNzm+r8DnxrCI/1PZ68iAEEtHMFdzsALZl8=; b=AINBVHDpMb2QNQLbxHYI US1IlwpYBU1QDpS24oI5hu+spjnP2qot1ISq/TTFYQCzTcuc84JCTlaMwbD8cv34AzoOPdXtiE5Df Vi7Bo18uRUsnXTQARVg93vVk3FiHj8PsoZksWZQuDmAyNnI6rBYmM3ZGdnyvkJuH7q+4nd5MGuVFY KfLaKHid9EcqXCBtSQ2bz6/KdD0H64jQedJ9q5HzOh/YZUB+fPcRQJjzv7cwbW+BhQz52JlWioUrL o20ME3R/ZpJ0NhppZrCTtEusW3Y6pWaigVsjuonFTdPC68fskkcaX2uYSxpbzN7rOQPi1gYpM1Y8G +yTJTsTvdD0uHA==; Original-Received: from [87.69.77.57] (port=1587 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 1nYpAC-0003SL-CM; Mon, 28 Mar 2022 09:12:04 -0400 In-Reply-To: <875ynytfce.fsf@gmail.com> (message from Robert Pluim on Mon, 28 Mar 2022 14:46:09 +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" Xref: news.gmane.io gmane.emacs.bugs:229012 Archived-At: > From: Robert Pluim > Cc: luangruo@yahoo.com, larsi@gnus.org, 54562@debbugs.gnu.org > Date: Mon, 28 Mar 2022 14:46:09 +0200 > > Eli> I guess we should try. It should be optional behavior, because Emacs > Eli> never did that, and I cannot predict what will that do to all the > Eli> different use cases where we compose text, and thus whether users will > Eli> like that in all the cases. It could, for example, mean that a > Eli> particular Latin character with a diacritic will be displayed with a > Eli> font that's different from the rest of the Latin text, which some > Eli> users might consider worse than seeing just the base character in the > Eli> "expected" font. And that's just the simplest use case. > > Yes, thatʼs exactly what happens with U+0308 here sometimes, see > screenshot below. I had to search a bit to find a font to use as the > default that didnʼt have a glyph for U+0308, so Iʼm not sure how > important this issue is in practice. I wasn't talking specifically about U+0308, I was talking about combining diacritics in general. Some newer ones could be missing from fonts that otherwise cover Latin character sets. > Eli> "Look at" in what sense? > > 'consider' > > Rough patch attached. It does U+20E3, U+0308, and U+20D0..U+20FF. It > works kind of ok, but U+006F U+0308 suffers from the font problem you > were worried about. With Bitstream Vera Mono, the composed glyph ends > up being from Latin Modern Roman, which looks very different. > > The composed glyphs for U+20D0..U+20FF look pretty bad in all the > fonts Iʼve tried so far: Unifont, FreeSans, Free Mono, Menlo, > Bitstream Vera Mono. Does anyone have an idea of a good font for > those? I'll let people comment on whether this is worth an optional behavior. > +static bool > +codepoint_is_combining_lookup_eligible (int ch) > +{ > + if ((0x20D0 <= ch && ch <= 0x20FF) || ch == 0x308) > + return true; > + return false; > +} Any reason not to use the Unicode category here? Or do we want to support only specific characters (in which case U+0308 is still not the only one)?