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: Sun, 16 Apr 2017 13:25:42 -0700 Organization: UCLA Computer Science Department Message-ID: <17547644-c802-588c-c620-ac1ed0e3e67c@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> <24bd0681-08d5-137f-29df-715eefddf2ae@cs.ucla.edu> <834lxqgipc.fsf@gnu.org> <11cfdd58-d2c2-b32f-ecc3-eb86db6711b8@cs.ucla.edu> <83o9vwgafr.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: quoted-printable X-Trace: blaine.gmane.org 1492374373 10432 195.159.176.226 (16 Apr 2017 20:26:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Apr 2017 20:26:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.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 Sun Apr 16 22:26:07 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 1czqkJ-0002YZ-2K for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Apr 2017 22:26:07 +0200 Original-Received: from localhost ([::1]:33498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czqkO-0008CQ-Lm for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Apr 2017 16:26:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czqkI-0008C6-0p for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 16:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czqkE-0005G5-SO for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 16:26:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52799) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1czqkE-0005Fm-Pa for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 16:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1czqkE-0007l6-Ek for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 16:26: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: Sun, 16 Apr 2017 20:26: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.149237435129809 (code B ref 26396); Sun, 16 Apr 2017 20:26:02 +0000 Original-Received: (at 26396) by debbugs.gnu.org; 16 Apr 2017 20:25:51 +0000 Original-Received: from localhost ([127.0.0.1]:50998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czqk3-0007kj-F0 for submit@debbugs.gnu.org; Sun, 16 Apr 2017 16:25:51 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czqk1-0007kV-G0 for 26396@debbugs.gnu.org; Sun, 16 Apr 2017 16:25:49 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DB2E5160083; Sun, 16 Apr 2017 13:25:43 -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 s5JpOtUPUMwE; Sun, 16 Apr 2017 13:25:43 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 16CF4160090; Sun, 16 Apr 2017 13:25:43 -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 JoBdGz4qfi2D; Sun, 16 Apr 2017 13:25:43 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.153.188.248]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EDEEE160083; Sun, 16 Apr 2017 13:25:42 -0700 (PDT) In-Reply-To: <83o9vwgafr.fsf@gnu.org> 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:131661 Archived-At: Eli Zaretskii wrote: > That depends on how easy it is to check whether the console is in > UTF-8 mode. Isn't that just another ioctl? Not as far as I know, for output mode. I looked for one and could not fin= d it. >>> and that the user >>> didn't override by a call to set-terminal-coding-system >> >> It might be simpler to not worry about this, under the argument that t= he Linux >> console is not a terminal in the usual sense. > > Once again, checking this is easy I don't see offhand how to distinguish a user's call to=20 set-terminal-coding-system from one that Emacs does internally as part of= its=20 existing heuristics. Plus, even if the user invokes set-terminal-coding-s= ystem,=20 when the Linux console is in UTF-8 mode (as it invariably is these days) = Emacs=20 will do the wrong thing if blindly follows the user's setting. > We've heard over the > years from several users who make a point of using non UTF-8 locales, On Linux consoles? Who does that nowadays? CJK locales have never worked on the Linux console, so the only concerns = here=20 are ISO 8859 Latin and Cyrillic consoles, that sort of thing. Generally=20 speaking, the rare people who care about Linux console encoding and want = to use=20 non-ASCII characters on their Linux consoles, switched from 8-bit locales= to=20 UTF-8 long ago: the code was added to Linux in 2007 and UTF-8 mode was ma= de the=20 default, and users took the usual one to three years to switch. So this i= s all=20 ancient history now by GNU/Linux standards. It's not clear that we can ev= en test=20 the old 8-bit mode any more; it didn't work on my Fedora 25 Linux console= when I=20 tried. It's a waste of time to write code that isn't needed and can't be = tested. > Glyphless characters are those that cannot be displayed. On GUI > frames, we determine that by looking up the character in the available > fonts; if none is available, we display the character as determined by > glyphless-char-display. On TTY frames, we do it differently, and the > way we do it doesn't currently consult the char-table created by > calculate_glyph_code_table. I'm saying that we should Yes, exactly. A frame connected to a Linux console should act like a GUI = frame=20 not an ordinary tty frame, because we know which characters the console c= an=20 display and we don't have to resort to guesswork and user settings like w= e do=20 with an ordinary tty frame.