bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Reuben Thomas
Subject: bug#28179: Fix use of string-to-multibyte in ispell.el
Date: Tue, 22 Aug 2017 18:04:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 22/08/17 17:38, Eli Zaretskii wrote:
From: Reuben Thomas <rrt@sc3d.org>
Date: Tue, 22 Aug 2017 01:51:53 +0100

 ;; Return a string decoded from Nth element of the current dictionary.
 (defun ispell-get-decoded-string (n)
   "Get the decoded string in slot N of the descriptor of the current dict."
   (let* ((slot (or
 		(assoc ispell-current-dictionary ispell-local-dictionary-alist)
 		(assoc ispell-current-dictionary ispell-dictionary-alist)
-		(error "No data for dictionary \"%s\", neither in `ispell-local-dictionary-alist' nor in `ispell-dictionary-alist'"
-		       ispell-current-dictionary)))
-	 (str (nth n slot)))
-    (when (and (> (length str) 0)
-	       (not (multibyte-string-p str)))
-      (setq str (ispell-decode-string str))
-      (or (multibyte-string-p str)
-	  (setq str (string-to-multibyte str))))
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”.

(My bold.)

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

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.

-- 
https://rrt.sc3d.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]