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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mattiase <at> acm.org, 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 17:26:04 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Mattias Engdegård <mattiase <at> acm.org>,
>   43632 <at> debbugs.gnu.org
> Date: Sat, 26 Sep 2020 16:22:10 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > It is not an anomaly.  If you want to see escapes, set
> > print-escape-nonascii non-nil.
> >
> > Also note that what you see is the result of 'eval' printing the
> > result, the real result (as returned by prin1) is a unibyte string:
> >
> >   (multibyte-string-p (prin1 "\377")) => nil
> >
> > (Yes, this is very confusing.)
> 
> Could we do something about this confusion?

I don't want to say no, but I'm sure it is at least very hard.

> This came up because I just couldn't make sense of what I was seeing
> when trying to work with raw bytes -- it seemed to be that Emacs was
> auto-promoting unibyte strings (with bytes >127) to multibyte strings...
> until I started calling multibyte-string-p on everything instead.

We indeed convert to multibyte when we insert text into a multibyte
buffer, and that's a feature.

> I'm guessing I'm not the only person confused by this stuff.

You are not.  I learned to use multibyte-string-p when in doubt.

Previous Next

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