GNU bug report logs - #27270
display-raw-bytes-as-hex generates ambiguous output for Emacs strings

Previous Next

Full log

Message #8 received at 27270 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: v.schneidermann <at> gmail.com, 27270 <at> debbugs.gnu.org
Subject: Re: bug#27270: display-raw-bytes-as-hex generates ambiguous output for
 Emacs strings
Date: Wed, 07 Jun 2017 08:17:04 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 6 Jun 2017 20:57:51 -0700
> Cc: Vasilij Schneidermann <v.schneidermann <at> gmail.com>
> 
> then on the terminal display I see:
> 
> x\x905y
> 
> If I cut and paste this (using my windowing system) into an Emacs string, like this:
> 
> "x\x905y"
> 
> and then evaluate the string, the result is the string "xअy"

display-raw-bytes-as-hex is a display-only feature, as its name tells,
it isn't supposed to affect evaluation or the Lisp reader.  So I'm
unsure why you expected it to affect evaluation.  It's the same if you
define a display table to display one character as another, and then
expect Emacs to perform the opposite transformation when it reads
characters or strings.

> A simple solution would be to display this instead:
> 
> x\x90\x35y

That would mean display-raw-bytes-as-hex is "viral", in that it
affects not just the raw byte, but also the next character.  That
sounds sub-optimal, as it makes reading the result harder.

> though that is awkward because it means the ASCII 0-9, a-f, A-F would be 
> displayed as hexadecimal escapes when they follow another hexadecimal escape. 

Exactly.

> By the way, I expected display-raw-bytes-as-hex to affect how Emacs displays 
> Emacs strings, too. Shouldn't it?

What do you mean by "Emacs strings"?  Buffer text is a string, isn't
it?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.