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#54032: 29.0.50; Emoji display on Linux console switched to hexadecimal output Date: Thu, 17 Feb 2022 09:52:15 +0200 Message-ID: <83ilte0w28.fsf@gnu.org> References: <87h78y56aj.fsf@sange.fi> 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="11274"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54032@debbugs.gnu.org To: Aura Kelloniemi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 17 09:08:26 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 1nKbpy-0002kK-9a for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Feb 2022 09:08:26 +0100 Original-Received: from localhost ([::1]:49442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKbpw-0002xZ-EQ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Feb 2022 03:08:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKbb5-0008TO-7R for bug-gnu-emacs@gnu.org; Thu, 17 Feb 2022 02:53:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56115) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nKbb4-00059t-TF for bug-gnu-emacs@gnu.org; Thu, 17 Feb 2022 02:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nKbb4-0007dD-BW for bug-gnu-emacs@gnu.org; Thu, 17 Feb 2022 02:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Feb 2022 07:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54032 X-GNU-PR-Package: emacs Original-Received: via spool by 54032-submit@debbugs.gnu.org id=B54032.164508434229286 (code B ref 54032); Thu, 17 Feb 2022 07:53:02 +0000 Original-Received: (at 54032) by debbugs.gnu.org; 17 Feb 2022 07:52:22 +0000 Original-Received: from localhost ([127.0.0.1]:50012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKbaP-0007cH-OY for submit@debbugs.gnu.org; Thu, 17 Feb 2022 02:52:22 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nKbaO-0007c4-1t for 54032@debbugs.gnu.org; Thu, 17 Feb 2022 02:52:20 -0500 Original-Received: from [2001:470:142:3::e] (port=44180 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 1nKbaF-00051F-3m; Thu, 17 Feb 2022 02:52:13 -0500 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=FOsGgkuZFCqN5AWZnGnOnMC+x4vqy7SPJ5DSerWvdXc=; b=mHvEfVVJqfapIAaIB4mr 4LUvth0WE/QLx+zeqyzQVIHHkLQ5zX8aO/5nEANBn04SZ3DlD9KnW3m73O1kckN2vKC2l91ApDkCB jmuNrCeL7SGX5EioxjrLeS4z4NIiudst/90V5xx5Es7xGmVZ/CRet4PEkm4AlPiJrZKJxJanl/Y3h XmAKuYb2Q3KCyevZuGYPBU8oHXI5lqhI1d54Tnun5favIng2VVm46JLpc7J47kJMpMO7/hut63Gxw q9MosnbzIHmRpzb+KNIIzT5ySSYpCZjexHSn2ezmmbuzY3RuIUKrQEWJlf+GM4zmDJ/ryAkOdfDFA Z5eXU3n0D7Rz3Q==; Original-Received: from [87.69.77.57] (port=4134 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 1nKbaC-0003PR-Ui; Thu, 17 Feb 2022 02:52:10 -0500 In-Reply-To: <87h78y56aj.fsf@sange.fi> (message from Aura Kelloniemi on Thu, 17 Feb 2022 08:57:40 +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:227071 Archived-At: > From: Aura Kelloniemi > Date: Thu, 17 Feb 2022 08:57:40 +0200 > > on recent Emacs development repository builds, emoji characters are no more > displayed on Linux console. Instead Emacs prints \UABCDEF hexadecimal codes. > > This is due to the commit 10c680551e899805a6de7360e9b65986fd87df72 which > probably makes things better on some terminals. Reverting this commit fixed > the issue for me, and emojis are again displayed as usual. Thanks, but I think we need more detailed information to understand the problem. First, when you say "display emoji characters", which characters exactly does that allude to? Can you show specific examples of text that includes Emoji, which displayed the Emoji glyphs before the above commit, but not after it? In particular, are we talking about single codepoints in the Emoji block, or are we talking about Emoji sequences that involve more than one codepoint (and are supposed to display like a single Emoji glyph)? For each example, please show both the text and what you see on display for that text. Also, what is the value of auto-composition-mode? I think it should be the string "linux", in which case please try setting it to t and see if the display becomes better or worse. > Linux console is (sort of) capable of displaying emojis. Console font can be > configured so that it has glyphs for emojis exactly the same way as for other > characters. If that is the case, why did Emacs think the terminal cannot display these characters? Can you step with GDB inside terminal_glyph_code, when it is called for the first time in the Emacs session, and see whether the ioctl call we issue in calculate_glyph_code_table returns valid values for the Emoji codepoints? > Also, blind users using refreshable braile displays use Linux > console to access Emacs. The braille terminal driver is able to detect the > correct character code points even when Linux itself is not able to display > them properly on the screen. This detection is done using the /dev/vcsu > (virtual console screen unicode) character devices. Are you saying that the braille terminal driver will not respond to the ioctl call we issue in calculate_glyph_code_table? Is there any other method of knowing which characters are supported in that case? > For these reasons it is important that emacs outputs the real > characters to the terminal on Linux console. Outputting codepoints for which there are no glyphs produced unreadable display, since (AFAIU) the console displays them all as the "diamond" replacement character. Detecting the fact that a codepoint cannot be displayed allows us to produce something that at least can be interpreted, and allows the user to install optional features (such as those provided by latin1-disp.el) which will replace the characters that cannot be displayed by equivalent strings, for example ASCII strings. So we would like to keep the automatic detection of whether a given character can be displayed by the console, although it sounds like the current solution should be made more flexible and sophisticated in some way. > Linux console has a terminal type string of "linux". lisp/term/linux.el > contains already some Linux terminal specific code (which unfortunately > assumes though that Linux has a default character set of Latin-1, which has > never been true). That's just the default. We attempt to detect which characters can be displayed later on, when the functions I mentioned above are called during startup. > My preferred solution to this problem would be to add and document a way to > configure character display logic on TTYs more precisely. It would be great to > be able to control the terminal output of Unicode on grapheme cluster > precision – i.e. allow the user to define a function which translates code > points/grapheme clusters into something that their terminal can display. I'm not yet sure something like that would be needed. It will certainly slow down the display on the console, which is undesirable for obvious reasons. It is also too complex (not every Emacs user can write Lisp programs that play sophisticated games with characters and glyphs). I think we don't yet have a detailed enough understanding of the issue to discuss solutions, so I suggest to postpone this discussion until the questions I asked above are answered, and we have a good understanding of what is going on. The commit to which you point out was made based on reports from another user of the Linux console (albeit not about Emoji), and in that case the change had a positive effect. So the issue is not simple, and we need a good understanding of it before we devise a solution. Thanks.