[Top][All Lists]

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

bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs

From: Paul Eggert
Subject: bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings
Date: Thu, 8 Jun 2017 09:24:56 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

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:


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.

reply via email to

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