Re: More confusion about multibyte vs unibyte strings

[Eli Zaretskii <eliz@gnu.org>]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 05 May 2022 11:44:41 -0700
> 
> > Why does it "mess things up", and what exactly is the nature of the
> > mess-up?  A pure-ASCII string can be either unibyte or multibyte, and
> > that shouldn't change a thing.
> 
> If the string is not ASCII, we need to encode it before sending to the
> server, and tell the server what encoding we used. Microsoft Exchange
> servers can't handle any encoding other than ascii.

What do you mean by "ascii encoding" in this context?

When you say that Microsoft Exchange can't handle any encoding other
than ascii, does it mean it cannot handle _any_ non-ASCII addressee
names?  That'd be hard to believe, because such addressee names are
nowadays in wide use.  So I guess you mean something else, but what?

> So if our code thinks a string isn't ascii, it sends the encoding
> message to the IMAP server, and Exchange blows up.

Encoding ascii yields a string that is identical to the original (IIUC
what you mean by "encoding"), so I don't follow you here.

> If the string is ascii, we don't try to encode it, and everything's
> fine. So I need to know whether the string is actually ascii or not.

You can do that using the regexp class [:ascii:], I guess.

> I can solve this some other way, like
> (equal (length str) (string-bytes str))

That should return non-nil for unibyte string that includes bytes
above 127 as well, no?

> but I'm just trying to figure out why this doesn't behave the way I
> expect it to. I'd thought that `multibyte-string-p' essentially
> performed the above length test.

No, it doesn't.  A pure ASCII string can be made multibyte without
changing its payload, and Emacs usually makes unibyte strings out of
pure ASCII characters.