Subject: bug#43632: Raw bytes printed as latin-1 in echo area and *Messages*

From: Eli Zaretskii <[email-masked]>
Date: Sat, 26 Sep 2020 19:10:10 +0300

> From: Mattias Engdegård <[email-masked]>
> Date: Sat, 26 Sep 2020 18:00:55 +0200
> Cc: [email-masked]
> 
> 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.