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

["Mattias Engdegård" <mattiase@acm.org>]

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.