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#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings Date: Thu, 8 Jun 2017 09:24:56 -0700 Organization: UCLA Computer Science Department Message-ID: <93d9c575-4eb2-ea9e-d998-a8f3cff33a1e@cs.ucla.edu> References: <29d6844f-2f6f-11c1-7877-a9d169e613f8@cs.ucla.edu> <83tw3s8jhr.fsf@gnu.org> <1c05b888-0c4a-05c8-248a-6e550637fff4@cs.ucla.edu> <8737bbxp6a.fsf@users.sourceforge.net> <2d5a8cd8-0884-bc1e-4298-a84dca61acbf@cs.ucla.edu> <831squ8no8.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 1496939177 22698 195.159.176.226 (8 Jun 2017 16:26:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Jun 2017 16:26:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 Cc: 27270@debbugs.gnu.org, v.schneidermann@gmail.com, npostavs@users.sourceforge.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 08 18:26:13 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 1dJ0GC-0005bz-Fe for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Jun 2017 18:26:12 +0200 Original-Received: from localhost ([::1]:50571 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJ0GH-0004x8-Jo for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Jun 2017 12:26:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJ0G9-0004vc-Cc for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2017 12:26:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJ0G2-0003L0-HR for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2017 12:26:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60870) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dJ0G2-0003Ke-Dg for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2017 12:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dJ0G2-0002UI-4T for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2017 12: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: Thu, 08 Jun 2017 16:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27270 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27270-submit@debbugs.gnu.org id=B27270.14969391089476 (code B ref 27270); Thu, 08 Jun 2017 16:26:02 +0000 Original-Received: (at 27270) by debbugs.gnu.org; 8 Jun 2017 16:25:08 +0000 Original-Received: from localhost ([127.0.0.1]:35314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJ0FA-0002Sm-2d for submit@debbugs.gnu.org; Thu, 08 Jun 2017 12:25:08 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJ0F7-0002SA-3t for 27270@debbugs.gnu.org; Thu, 08 Jun 2017 12:25:05 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 54F581600D1; Thu, 8 Jun 2017 09:24:58 -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 o7_mGN84x_LT; Thu, 8 Jun 2017 09:24:57 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 954FB1600D2; Thu, 8 Jun 2017 09:24:57 -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 kLDxw619fIG5; Thu, 8 Jun 2017 09:24:57 -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 2CABA1600D1; Thu, 8 Jun 2017 09:24:57 -0700 (PDT) In-Reply-To: <831squ8no8.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:133402 Archived-At: On 06/08/2017 09:11 AM, Eli Zaretskii wrote: >> (setq display-raw-bytes-as-hex t) C-j >> (format "%c%c" ?\u0090 ?5) C-j >> >> Emacs displays this: >> >> "\x905" >> >> which is the wrong string visually. > How is that different from "\2205" you get under the default settings? When I cut and paste "\2205" into another Emacs, it evaluates to the same two-character string that I started off with because octal escapes are limited to 3 octal digits. When I cut and paste "\x905" I get a one-character string because there is no limit to the length of hexadecimal escapes. This is a problem, because cut-and-paste should continue to copy text accurately even when I'm using terminal windows. >> The string should be >> displayed unambiguously, either like this: >> >> "\x80\ 5" >> >> or via some other means. > We do use "some other means": the raw byte has a different face. That doesn't help when --color=no is specified, or in terminal sessions that do not support colors. And the colors, even when present, do not survive cutting and pasting, which copies the text without colors. So this is a real problem. > But if you evaluate the above in*scratch*, you won't see that because of > font-lock. Turn off font-lock-mode, and you will clearly see where > the raw byte ends and "normal" text begins. Turning off font-lock-mode doesn't help when colors are disabled. I often run with colors disabled, since my terminal color scheme disagrees with Emacs's and I prefer monochrome anyway. So this ambiguity will be a real pain for me.