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

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 7 Jun 2017 03:59:01 UTC

Severity: wishlist

Tags: moreinfo

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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, npostavs <at> users.sourceforge.net
Subject: bug#27270: display-raw-bytes-as-hex generates ambiguous output for Emacs strings
Date: Thu, 08 Jun 2017 21:59:56 +0300
> Cc: npostavs <at> users.sourceforge.net, 27270 <at> debbugs.gnu.org,
>  v.schneidermann <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 8 Jun 2017 09:24:56 -0700
> 
> >> "\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.

That's a different issue.  You said "\x905" was wrong visually, so I
asked how is that different, visually, from "\2205".

> 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.

Same thing happens when you copy/paste from an Emacs window which uses
a display table: the pasted string will be different from the original
one.  I believe I already pointed that out in this discussion.

> >> "\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.

In those cases, the octal notation has the same visual problems.

> I prefer monochrome anyway. So this ambiguity will be a real pain
> for me.

I still don't understand how this is different from the octal
notation, but if it is, you can always stay with the default octal
display.  That's what I do.




This bug report was last modified 3 years and 109 days ago.

Previous Next


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