GNU bug report logs - #43632
Raw bytes printed as latin-1 in echo area and *Messages*

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 43632 <at> debbugs.gnu.org
Subject: Re: bug#43632: Raw bytes printed as latin-1 in echo area and
 *Messages*
Date: Sat, 26 Sep 2020 19:10:10 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 26 Sep 2020 18:00:55 +0200
> Cc: 43632 <at> debbugs.gnu.org
> 
> Why, then, is the echo area not treated as a multibyte buffer in
> this regard?

It is.  That's not the reason.

> If the behaviour of (prin1 x t) cannot be changed, then what about eval-expression (M-|)? Being an interactive command, surely compatibility isn't an obstacle to making it more useful?

We were talking about M-:.  And that does call prin1.  And prin1 does
produce a unibyte string, the reason for the display that confused you
is elsewhere.

> It would also be interesting to know why, when print-escape-nonascii is nil, unibyte strings are decoded specifically as Latin-1 (and not, say, UTF-8). I presume it is an artefact of history.

They are not decoded as Latin-1, they are simply inserted into a
buffer as a single byte.  And we do it regardless of
print-escape-nonascii, because \377 is the Unicode (and Latin-1)
codepoint of ÿ.

So it isn't a historical artifact.  I think it's simply a consequence
of how print functions work.

Previous Next

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