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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, v.schneidermann <at> gmail.com,
 27270 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#27270: display-raw-bytes-as-hex generates ambiguous output
 for Emacs strings
Date: Sat, 23 Apr 2022 16:00:31 +0200

[Message part 1 (text/plain, inline)]

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

> The idea is to add a new \X escape for character constants and
> strings. This escape would allow at most two hexadecimal digits,
> rather than the unlimited number of digits that \x does. For example,
> the Lisp string "\XABC" would be equivalent to the Lisp string "\xAB\
> C", that is, it would be a two-character string containing the
> character U+00AB LEFT POINTING GUILLEMET followed by the character
> U+0043 LATIN CAPITAL LETTER C.

This was four years ago, but I don't think any steps were taken in this
direction, beyond marking the raw bytes more clearly:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

Even in *scratch*, where font-locking overrode those, I think?

The issue still remains -- if you do this in emacs -nw:

(format "%c5" 128)
"€5"

And cut and paste that do a different Emacs, you get the string

"\x805"
=> "ࠅ"

But...  we've had this format for half a decade now, and this doesn't
really seem to be a problem in practice, so while the format is somewhat
ambiguous, I tend to think that introducing a new syntax just to fix it
isn't worth it.  Especially a syntax like \x{80}, which was one of the
suggestions -- the idea, after all, is to make display prettier and more
readable.

Any further opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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