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

Previous Next

Full log

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.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 18:00:55 +0200

26 sep. 2020 kl. 16.14 skrev Eli Zaretskii <eliz <at> 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.

Previous Next

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