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

[Mattias Engdegård]

26 sep. 2020 kl. 16.14 skrev Eli Zaretskii <eliz@gnu.org>:

First, thank you for your quick answer.

> If you want to see escapes, set
> print-escape-nonascii non-nil.

Certainly, but that isn't needed when printing to a buffer, as in (prin1 
"\377").

The print-escape-nonascii docs say

  When the output goes in a multibyte buffer, this feature is
  enabled regardless of the value of the variable.

Why, then, is the echo area not treated as a multibyte buffer in this regard? 
Is there a practical reason or is it an artefact of history that cannot be 
changed?

(Note that the echo area buffers, the minibuffer, and *Messages* are all 
multibyte.)

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?

I'm assuming that it would be more useful to see raw bytes shown octal-escaped 
or otherwise visually distinct from their interpretation as Latin-1. If nothing 
else, it would make sense to have the same behaviour as when evaluating 
something in *scratch*.

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.