[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28179: Fix use of string-to-multibyte in ispell.el
From: |
Eli Zaretskii |
Subject: |
bug#28179: Fix use of string-to-multibyte in ispell.el |
Date: |
Tue, 22 Aug 2017 20:23:44 +0300 |
> 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?