Re: More confusion about multibyte vs unibyte strings

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 05 May 2022 09:58:43 -0700
>> 
>> The function above uses `multibyte-string-p' to test whether the string
>> needs the extra handling. This works correctly in the minibuffer and
>> *scratch*:
>> 
>> (multibyte-string-p "FROM eric") -> nil
>> 
>> (multibyte-string-p "FROM 张三") -> t
>> 
>> but when I edebug the code during an actual IMAP search, the test
>> returns t for both strings, which messes things up.
>
> 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. So if our code thinks
a string isn't ascii, it sends the encoding message to the IMAP server,
and Exchange blows up. 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.

I can solve this some other way, like
(equal (length str) (string-bytes str))
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.