From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty Date: Fri, 14 Apr 2017 11:56:32 -0700 Organization: UCLA Computer Science Department Message-ID: <24bd0681-08d5-137f-29df-715eefddf2ae@cs.ucla.edu> 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> <83inm7go6o.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1492196236 13646 195.159.176.226 (14 Apr 2017 18:57:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 18:57:16 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 Cc: user42_kevin@yahoo.com.au, 26396@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 14 20:57:08 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 1cz6P5-0003Kj-SJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Apr 2017 20:57:08 +0200 Original-Received: from localhost ([::1]:54314 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz6PB-0000K7-QD for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Apr 2017 14:57:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cz6P5-0000Je-47 for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 14:57:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cz6P2-0003B4-1E for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 14:57:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49284) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cz6P1-0003Az-TA for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 14:57:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cz6P0-0005k8-2n for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2017 14:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2017 18:57:02 +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.149219620422052 (code B ref 26396); Fri, 14 Apr 2017 18:57:02 +0000 Original-Received: (at 26396) by debbugs.gnu.org; 14 Apr 2017 18:56:44 +0000 Original-Received: from localhost ([127.0.0.1]:47483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz6Oh-0005jb-Mm for submit@debbugs.gnu.org; Fri, 14 Apr 2017 14:56:44 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz6Of-0005jN-Jp for 26396@debbugs.gnu.org; Fri, 14 Apr 2017 14:56:42 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A064B1600FE; Fri, 14 Apr 2017 11:56:34 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id n2jnpAdZj8Km; Fri, 14 Apr 2017 11:56:33 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 65106160100; Fri, 14 Apr 2017 11:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id grd2JpkAXrYw; Fri, 14 Apr 2017 11:56:33 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1FA701600FE; Fri, 14 Apr 2017 11:56:33 -0700 (PDT) In-Reply-To: <83inm7go6o.fsf@gnu.org> Content-Language: en-US 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:131579 Archived-At: On 04/14/2017 05:37 AM, Eli Zaretskii wrote: >> 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? I haven't experimented with it, so I'm not 100% sure. However, as I understand the implementation, the console driver can support at most 512 simultaneously-displayable characters, as this is a property of the classic IBM VGA design that is the greatest common denominator of current or recent (post-1990) PC graphics hardware. The user can specify what each character looks like down to the pixel level, but cannot alter character sizes on a character-by-character basis. In theory one could display double-wide characters by splitting them into halves and displaying each half separately, but I don't know of anyone who does that (it would not be practical due to that 512 limit). > >>> 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? It's done at boot time. The escape sequences ESC % G (or ESC % 8) and ESC % @ get you into and out of UTF-8 mode; see . Common practice is to stay in UTF-8 mode as the alternative is worse (it has only 256 simultaneously-displayable characters). > http://www.tldp.org/LDP/LG/issue91/loozzr.html > http://man7.org/linux/man-pages/man4/console_codes.4.html > that seems to be just the tip of an iceberg. Or maybe the > issue is easier than I envisioned. Both, I hope. :-) > 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? No, because a character is displayable only if it's in that set of at-most-512 characters. > 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? terminal_glyph_code gets the current set of at-most-512 displayable characters from from the kernel.