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: Sat, 10 Jun 2017 17:04:40 -0700 Organization: UCLA Computer Science Department Message-ID: 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> <93d9c575-4eb2-ea9e-d998-a8f3cff33a1e@cs.ucla.edu> <83y3t271ar.fsf@gnu.org> <83shja6yoq.fsf@gnu.org> <83r2yt7lad.fsf@gnu.org> <2202b54b-606f-0a10-abf7-5cb1a9164897@cs.ucla.edu> <83h8zo71au.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 1497139516 23936 195.159.176.226 (11 Jun 2017 00:05:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Jun 2017 00:05:16 +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 Sun Jun 11 02:05:12 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 1dJqNS-0005yS-Ms for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jun 2017 02:05:10 +0200 Original-Received: from localhost ([::1]:60600 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJqNX-00052X-M6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Jun 2017 20:05:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJqNP-00050z-JN for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2017 20:05:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJqNM-00024y-FN for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2017 20:05:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36849) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dJqNM-00024u-Bp for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2017 20:05:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dJqNK-0002CH-Bq for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2017 20:05:03 -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, 11 Jun 2017 00:05: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.14971394928425 (code B ref 27270); Sun, 11 Jun 2017 00:05:02 +0000 Original-Received: (at 27270) by debbugs.gnu.org; 11 Jun 2017 00:04:52 +0000 Original-Received: from localhost ([127.0.0.1]:39526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJqN8-0002Bo-SY for submit@debbugs.gnu.org; Sat, 10 Jun 2017 20:04:51 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJqN6-0002Bb-AB for 27270@debbugs.gnu.org; Sat, 10 Jun 2017 20:04:48 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6F39D1600D3; Sat, 10 Jun 2017 17:04:42 -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 4oaeEnlHnijp; Sat, 10 Jun 2017 17:04:41 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A3B091600E7; Sat, 10 Jun 2017 17:04:41 -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 If152uwKjmCU; Sat, 10 Jun 2017 17:04:41 -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 52F661600D3; Sat, 10 Jun 2017 17:04:41 -0700 (PDT) In-Reply-To: <83h8zo71au.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:133456 Archived-At: On 06/10/2017 12:24 AM, Eli Zaretskii wrote: > So your proposal would mean a change to the Lisp reader to support > such escapes, right? If so, isn't such a change > backward-incompatible? Yes, but only in the sense that undocumented escapes evaluate to themselves, e.g., "\F" is currently the same as "F" in Emacs Lisp because there is no escape sequence \F currently defined for character constants. But there's nothing new here, e.g., when we added "\N{...}" last year we changed the interpretation of the formerly-undocumented \N escape. >> Also, display-raw-bytes-as-hex would cause raw bytes to be displayed with this >> new X escape, rather than with with the x escape. > It could only do that for codepoints below 256 decimal, so that > limitation should be taken into account when deciding on the proposal. Ouch, I hadn't thought of that. Wait -- doesn't that mean that "display-raw-bytes-as-hex" is a misleading name, because it affects the display not only of raw bytes, but of other undisplayable characters? Shouldn't we change its name to something more generic and more accurate, like "display-characters-as-hex"? Anyway, to address the point you raised: how about a different idea? We extend the existing \x syntax in strings so that \x{dddd} has the same meaning as "\xdddd", except that the "}" terminates the escape. This syntax is used by Perl and so is in the same family as \N{...}. We also change display-raw-bytes-as-hex to use this new syntax when a character is immediately followed by a hexadecimal digit. That way, most characters are displayed as before, but my problematic example is displayed as "x\x{90}5y", which is a good visual cue of the unusual situation.