bug#28179: Fix use of string-to-multibyte in ispell.el

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 28179@debbugs.gnu.org
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 22 Aug 2017 18:04:11 +0100
> 
> Are you sure we don't need to ensure ispell-get-decoded-string always
> returns a multibyte string?  What if decode-coding-string returns a
> pure ASCII string, which is therefore unibyte?
> 
> This is multibyte too, no? The Emacs manual says:
> 
>  Rather, Emacs uses a variable-length internal representation of
>  characters, that stores each character as a sequence of 1 to 5 8-bit
>  bytes, depending on the magnitude of its codepoint(1). For example, any
>  ASCII character takes up only 1 byte, a Latin-1 character takes up 2
>  bytes, etc. We call this representation of text “multibyte”.

This is a misunderstanding, caused by the overloaded meaning of
"multibyte string".  The way I meant it, it has to do with the
internal flag marking a string either unibyte or multibyte.  Observe:

  (multibyte-string-p "abcd") => nil

but

  (multibyte-string-p (decode-coding-string "abcd" 'utf-8)) => t

although

  (string= "abcd" (decode-coding-string "abcd" 'utf-8)) => t

> The reason I am using decode-coding-string is because that is what the obsolescence message in subr.el
> says to use.

Yes, but the code already used decode-coding-string, in the function
ispell-decode-string, which you replaced with its body.  The call to
string-to-multibyte worked on the result of decoding, not instead of
the decoding.  So actually the call to string-to-multibyte was not
replaced, it was removed.

> If I've overlooked something, then it would be nice to know what I've missed in the documentation, or whether
> the documentation could be improved.

Is the issue more clear now?