From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty Date: Fri, 14 Apr 2017 15:37:35 +0300 Message-ID: <83inm7go6o.fsf@gnu.org> References: <87efx31vxy.fsf@blah.blah> <83o9w7mjlj.fsf@gnu.org> <87k26u9n4t.fsf@blah.blah> <83h91wlpws.fsf@gnu.org> <83fuhglp42.fsf@gnu.org> <47a950c4-2a4b-dfab-36e4-2b691b406b5f@cs.ucla.edu> <83bms0ixq2.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492173501 11536 195.159.176.226 (14 Apr 2017 12:38:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 12:38:21 +0000 (UTC) Cc: user42_kevin@yahoo.com.au, 26396@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 14 14:38:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz0UO-0002pB-3I for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Apr 2017 14:38:12 +0200 Original-Received: from localhost ([::1]:53150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz0UR-0000pQ-S4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Apr 2017 08:38:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz0UJ-0000oe-Vs for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 08:38:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz0UE-0007ZY-7g for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 08:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48390) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cz0UE-0007ZS-3w for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 08:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cz0UD-0008Hb-UJ for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 08:38: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: Fri, 14 Apr 2017 12:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26396 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26396-submit@debbugs.gnu.org id=B26396.149217344631796 (code B ref 26396); Fri, 14 Apr 2017 12:38:01 +0000 Original-Received: (at 26396) by debbugs.gnu.org; 14 Apr 2017 12:37:26 +0000 Original-Received: from localhost ([127.0.0.1]:46589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz0Ta-0008Gi-0b for submit@debbugs.gnu.org; Fri, 14 Apr 2017 08:37:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz0TZ-0008GW-0v for 26396@debbugs.gnu.org; Fri, 14 Apr 2017 08:37:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz0TP-0007E5-Tt for 26396@debbugs.gnu.org; Fri, 14 Apr 2017 08:37:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz0TP-0007Dz-QD; Fri, 14 Apr 2017 08:37:11 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2405 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cz0TP-0001XF-2S; Fri, 14 Apr 2017 08:37:11 -0400 In-reply-to: (message from Paul Eggert on Thu, 13 Apr 2017 13:58:45 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:131572 Archived-At: > Cc: user42_kevin@yahoo.com.au, 26396@debbugs.gnu.org > From: Paul Eggert > Date: Thu, 13 Apr 2017 13:58:45 -0700 > > On 04/13/2017 12:16 AM, Eli Zaretskii wrote: > > Yes, that would be better. But it's probably a non-trivial project, > > since we'd need separate code to determine double-width glyphs, > > padding glyphs, and perhaps also something special for composed > > characters. Does the Linux console allow us to figure out all of > > that? > > This should not be a problem, as the Linux console has only single-width > characters. Are you sure? AFAIU, the Linux console supports the BMP, and some of the characters in the BMP are double-width (a.k.a. "full-width"), for example U+1100, U+231A, U+2B1B, and others. What does the Linux console do when these characters are sent to the screen driver? > > And what does "display as-is" means in practice? Should we send to > > the console the glyph codes corresponding to Unicode points, or should > > we send UTF-8 encoded characters? > > It depends on whether the console is in UTF-8 mode. If so, send UTF-8; > if not, send a byte that is transformed according to the current mapping > table into a Unicode value. I hope we don't need to bother with the > latter possibility. What software puts the console in UTF-8 mode? Is that the locale setting? > > (Is there some document which > > describes these features in enough detail for us to figure out their > > implications on Emacs display code?) > > Nothing definitive, but there is: > > http://www.tldp.org/LDP/LG/issue91/loozzr.html > http://man7.org/linux/man-pages/man4/console_codes.4.html Thanks, but that seems to be just the tip of an iceberg. Or maybe the issue is easier than I envisioned. Suppose we only wanted to use this feature for UTF-8 locales. Assuming that the OS takes care of putting the console in UTF-8 mode, we don't need any changes in Emacs, since Emacs already sends UTF-8 sequences to the screen driver. As the Linux console only supports the BMP, we could then simply amend the code of char-displayable-p to check whether a character is within the BMP, when the terminal is the Linux console. Do you agree with this conclusion? OTOH, now I'm not sure I understand the need for terminal_glyph_code. What does it do that a simple check for a Linux console and UTF-8 terminal encoding, plus a character being inside a BMP, don't?