From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#28179: Fwd: Re: bug#28179: Fix use of string-to-multibyte in ispell.el Date: Thu, 24 Aug 2017 19:50:17 +0100 Message-ID: References: <0df1f5ab-e99b-b473-549c-5a40045ab71a@sc3d.org> <83lgm89a1v.fsf@gnu.org> <4d1a7990-f076-9e22-39df-6edeef17ef7b@sc3d.org> <83a82o969t.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503600685 862 195.159.176.226 (24 Aug 2017 18:51:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 18:51:25 +0000 (UTC) Cc: 28179@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 24 20:51:19 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkxDc-0007dP-V8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Aug 2017 20:51:05 +0200 Original-Received: from localhost ([::1]:49951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkxDj-0006AX-NI for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Aug 2017 14:51:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkxDd-0006AA-Bd for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 14:51:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkxDa-00053L-7H for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 14:51:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44484) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkxDa-000538-3F for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 14:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dkxDZ-0001CM-Mo for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 14:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2017 18:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28179 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28179-submit@debbugs.gnu.org id=B28179.15036006274566 (code B ref 28179); Thu, 24 Aug 2017 18:51:01 +0000 Original-Received: (at 28179) by debbugs.gnu.org; 24 Aug 2017 18:50:27 +0000 Original-Received: from localhost ([127.0.0.1]:53165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkxD1-0001Ba-JV for submit@debbugs.gnu.org; Thu, 24 Aug 2017 14:50:27 -0400 Original-Received: from mail-oi0-f54.google.com ([209.85.218.54]:34923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkxCz-0001BM-2g for 28179@debbugs.gnu.org; Thu, 24 Aug 2017 14:50:25 -0400 Original-Received: by mail-oi0-f54.google.com with SMTP id k77so3073071oib.2 for <28179@debbugs.gnu.org>; Thu, 24 Aug 2017 11:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5sM02P8aYmDdhN14lfDeHxagIMj7/wT/l5Ohbw6W35A=; b=d//P/jQ4Iy/YOAj8IpK3uTMo54sSKbtoaFk6uJ+9VM4UTaYdkJbjXea5JsSxhXFzEs Qry7fP3pQa5hPtZ2yoLwfkwTrJ+PEfEng6UkoyQyieAznXUS00kPg9Z1daQ5b58+GAie afjltKDNZGjzahE2uQw7V1zuuivTZEDDi3Ac8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5sM02P8aYmDdhN14lfDeHxagIMj7/wT/l5Ohbw6W35A=; b=Z+UA0qkGud/xkOfzwGM3CaAeH8A+ReiJdIg01+2sXaP5dtgn0M5CNR9PMdB/D4/j7J 9TyLoHOmIEnkM0YPZi5B2vY+v+UwKJvWQCmhacojy/07+J8aFGrWEAAXxrmfTbI0UHzH ixBTJOWbggiHtm5eFJHe+4NWJhOG5kVTu2DNp4Wsk7kJinp3CvHamKvc5Yp7BWAZXLeX WmB6lbkXB9AZRsLoA83DjRd16OdZs2RYADAWkEloTtJtnG6mWztpV30aelLH8vJ9rYm5 3MLwrXCs5uLebYaltEjbc8kNGA1qK69XL862N9zsTVPqRqnprJkXPEkZ682pi8DQirHz eqKg== X-Gm-Message-State: AHYfb5jxywnGYKLPTl2fmnyukDi+gjb0z8rrmCYecCZRz6cupkSk/Otk kyiyq77+3n+DeyWgCSMQkPC2age/oLzYkBM= X-Received: by 10.202.252.199 with SMTP id a190mr9806604oii.268.1503600618043; Thu, 24 Aug 2017 11:50:18 -0700 (PDT) Original-Received: by 10.157.60.154 with HTTP; Thu, 24 Aug 2017 11:50:17 -0700 (PDT) In-Reply-To: <83a82o969t.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136161 Archived-At: On 24 August 2017 at 19:20, Eli Zaretskii wrote: >> Cc: 28179@debbugs.gnu.org >> From: Reuben Thomas >> Date: Thu, 24 Aug 2017 18:45:33 +0100 >> >> The reason I am asking again is because you first said: >> >> > What if decode-coding-string returns a pure ASCII string, which is >> > therefore unibyte? >> >> and then later you said: >> >> > 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 > > That example may be conclusive for UTF-8, but is it conclusive for > _any_ encoding? I don't know. E.g., what about the ISO-2022 based > encodings, where all the bytes are (AFAIR) pure ASCII? (multibyte-string-p (decode-coding-string "abcd" 'iso-2022-jp)) => t I still don't understand what you're getting at: the bytes in "abcd" are pure ASCII, whatever coding system one is decoding from. > Can you show me why 2 is always correct? It might be, I simply don't > know. All I know is that in general relying on plain-ASCII strings to > be always multibyte in any given situation is risky, we were bitten by > that a few times. But maybe it's not an issue in this case. Which is > why I was asking you whether you have sufficient basis to believe this > to be so in this case. I don't know. As I said before, the make-obsolete notice for string-to-multibyte says "use `decode-coding-string'". If it is as tricky as you suggest it might be, then the notice should be updated to point to more detailed guidance. The relevant commit is: commit f74d496478cd57f252817bd7437fe1b7972ce01f Author: Stefan Monnier Date: Mon Jan 30 13:02:18 2017 -0500 * lisp/subr.el (string-make-unibyte, string-make-multibyte): Obsolete. diff --git a/lisp/subr.el b/lisp/subr.el index a6ba05c..a204577 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1417,8 +1417,10 @@ posn-object-width-height ;; bug#23850 (make-obsolete 'string-to-unibyte "use `encode-coding-string'." "26.1") (make-obsolete 'string-as-unibyte "use `encode-coding-string'." "26.1") +(make-obsolete 'string-make-unibyte "use `encode-coding-string'." "26.1") (make-obsolete 'string-to-multibyte "use `decode-coding-string'." "26.1") (make-obsolete 'string-as-multibyte "use `decode-coding-string'." "26.1") +(make-obsolete 'string-make-multibyte "use `decode-coding-string'." "26.1") I'm going to close this bug; if better documentation is needed, both for the obsolescence of string-to-multibyte and for multibyte strings in general, that's a new bug. -- https://rrt.sc3d.org