emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27270: closed (display-raw-bytes-as-hex generates ambiguous output f


From: GNU bug Tracking System
Subject: bug#27270: closed (display-raw-bytes-as-hex generates ambiguous output for Emacs strings)
Date: Thu, 28 Apr 2022 17:59:02 +0000

Your message dated Thu, 28 Apr 2022 10:58:33 -0700
with message-id <742c3a8c-fdfa-cf9a-c033-597944c58b1f@cs.ucla.edu>
and subject line Re: bug#27270: display-raw-bytes-as-hex generates ambiguous 
output for Emacs strings
has caused the debbugs.gnu.org bug report #27270,
regarding display-raw-bytes-as-hex generates ambiguous output for Emacs strings
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
27270: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27270
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: display-raw-bytes-as-hex generates ambiguous output for Emacs strings Date: Tue, 6 Jun 2017 20:57:51 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 With the default octal display format one can copy text out of a terminal window and into an Emacs string, reliably. With the new hex display this doesn't work any more, unfortunately. For example, if I run this shell script:

printf 'x\2205y\n' >foo.txt
LC_ALL=C emacs -nw --color=no --eval '(progn (setq display-raw-bytes-as-hex t) (find-file-literally "foo.txt"))'

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", that is, a 3-character string with the characters "x", "अ", and "y", where the middle character is U+090F DEVANAGARI LETTER A. This is an incorrect representation, as the buffer actually contains the four characters "x", "\x90", "5", and "y". The problem is that the string has glued together the representation of the character "\x90" to the representation of the character "5", resulting in the representation of the character "\x905" which is not accurate.

Please change the behavior of display-raw-bytes-as-hex so that it is not ambiguous in this way.

A simple solution would be to display this instead:

x\x90\x35y

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. Perhaps we can think of a better approach. One possibility would be to define and use a new string escape \Xxx that contains at most two hex digits.

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



--- End Message ---
--- Begin Message --- Subject: Re: bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings Date: Thu, 28 Apr 2022 10:58:33 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
On 4/27/22 10:22, Lars Ingebrigtsen wrote:
Paul Eggert <eggert@cs.ucla.edu> writes:

Could you explain what you mean by "change the output"? (Sorry, I'm
not seeing it.)

I said earlier:

display-raw-bytes-as-hex is a display setting.  You want to change it so
that the data output will be different

Still not quite following, as I had been thinking more recently of changing only how display-raw-bytes-as-hex displays.

That being said, I looked into the code and found that what I was asking for would be quite a pain to implement - more trouble than it's worth, anyway - so I withdraw the suggestion and am closing the bug report.

I installed the attached, which documents the situation.

Attachment: 0001-Document-807-etc.-in-raw-byte-display.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]