From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Displaying bytes (was: Inadequate documentation of silly characters on screen.) Date: Mon, 23 Nov 2009 15:38:41 -0500 Message-ID: References: <20091119082040.GA1720@muc.de> <874ooq8xay.fsf@wanchan.jasonrumney.net> <20091119141852.GC1720@muc.de> <20091119155848.GB1314@muc.de> <87aayiihe9.fsf@lola.goethe.zz> <20091119180848.GE1314@muc.de> <47325.130.55.118.19.1258658705.squirrel@webmail.lanl.gov> <20091119212550.GG1314@muc.de> <87my2ign8u.fsf@lola.goethe.zz> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1259010031 12102 80.91.229.12 (23 Nov 2009 21:00:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 21:00:31 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 22:00:23 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NCg1G-0008CA-Gm for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 22:00:22 +0100 Original-Received: from localhost ([127.0.0.1]:56534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCg1G-0005Jx-2P for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 16:00:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCfgN-0006Hi-Ai for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:38:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCfgI-0006FC-Ie for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:38:46 -0500 Original-Received: from [199.232.76.173] (port=45054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCfgI-0006Ev-6y for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:38:42 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:34520) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCfgH-0004QC-UN for emacs-devel@gnu.org; Mon, 23 Nov 2009 15:38:42 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NCfgH-00048l-CC; Mon, 23 Nov 2009 15:38:41 -0500 In-reply-to: (message from Stefan Monnier on Sun, 22 Nov 2009 21:08:28 -0500) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:117621 Archived-At: > Basically, it isn't clear that \361 is a byte rather than a character, > and what difference that ought to make, and what you should do > if you want to turn it from a byte into a character. So how do you suggest we represent the byte 241? No better way jumps into my mind. But maybe we could figure out some way to make the current way easier to understand. For instance, C-u C-x = on \224 says character: ” (4194196, #o17777624, #x3fff94) preferred charset: tis620-2533 (TIS620.2533) code point: 0x94 syntax: w which means: word buffer code: #x94 file code: #x94 (encoded by coding system no-conversion) display: not encodable for terminal Character code properties: customize what to show [back] Perhaps it should say, character: Stray byte ” (4194196, #o17777624, #x3fff94) What are the situations where a user is likely to see these stray bytes. When visiting a binary file, of course; but in that situation, nobody will be surprised or disappointed. So what are the other cases, and what might the user really want instead? Does it mean the user probably wants to do M-x decode-coding-region? If so, can we find a way to give the user that hint? When I click on tis620-2533 in that output, I get this Character set: tis620-2533 TIS620.2533 Number of contained characters: 256 ASCII compatible. Code space: [0 255] [back] which is totally unhelpful. What is this character set's main purpose? Does it exist specifically for stray non-ASCII bytes? If so, saying so here would help. If not -- if it has some other purpose -- then it would be good to explain both purposes here. Also, if it exists for these stray non-ASCII bytes, why does it have 256 chars in it? There are only 128 possible stray non-ASCII bytes. (It is also not clear to me what "ASCII compatible" means in this context.)