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 18:45:33 +0100 Organization: =?UTF-8?Q?SC=C2=B3D?= Message-ID: <4d1a7990-f076-9e22-39df-6edeef17ef7b@sc3d.org> References: <0df1f5ab-e99b-b473-549c-5a40045ab71a@sc3d.org> <83lgm89a1v.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1503596836 26083 195.159.176.226 (24 Aug 2017 17:47:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 17:47:16 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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 19:47:10 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 1dkwDc-0005yF-NM for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Aug 2017 19:47:01 +0200 Original-Received: from localhost ([::1]:49704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwDj-0003Um-8u for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Aug 2017 13:47:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkwCl-0002s0-6J for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 13:46:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkwCg-00017D-BP for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 13:46:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkwCg-000176-7g for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 13:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dkwCf-0006Ff-Vx for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2017 13:46:02 -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 17:46: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.150359675024013 (code B ref 28179); Thu, 24 Aug 2017 17:46:01 +0000 Original-Received: (at 28179) by debbugs.gnu.org; 24 Aug 2017 17:45:50 +0000 Original-Received: from localhost ([127.0.0.1]:53099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkwCT-0006FF-NK for submit@debbugs.gnu.org; Thu, 24 Aug 2017 13:45:49 -0400 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:35614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkwCR-0006F3-VY for 28179@debbugs.gnu.org; Thu, 24 Aug 2017 13:45:48 -0400 Original-Received: by mail-wm0-f43.google.com with SMTP id b189so1171276wmd.0 for <28179@debbugs.gnu.org>; Thu, 24 Aug 2017 10:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WdKSZcRykexCb2azYCuIqUNd4ynsvmONGw06iOml0go=; b=smEMhSlGiFsk2alXmJGKqacYgOYUTmi0Wi0sxvUCkcSS2cO2ZvD/8oB31VEt+gVXFt UH4a0/O2B0q3LbwvNvAV6ucZ8sb2HnX3atQZ/Aa108EWzBOhP7LaB4IWoHR6qeWCneM0 b4EzHrsbQuqVPaDp18cSDQ3ETTnhrZsybGQU0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=WdKSZcRykexCb2azYCuIqUNd4ynsvmONGw06iOml0go=; b=qxyDWWnM/23v89xFlHc/2TWSlfEvuyJWfutYcWqw/Umcn2mEBlNjleepIY6mjPdbb0 JjIwxvN/998UGy7kZPfHrMI9CSCKHSuGRAGPg55pdUqkdi2YaxIY4cgAUMwEC/ZwGVo/ l8Jcq2QPkfO78AwO70IEZzN8uaYL9J1t8p4AT+d+XzkoWY6LdXMVs/H6e+dGX3tmjsjj O9a7UmIue+saoq+MbuKm6ZZX3pCaCPj+VTzYj5CYzmPswkRPY1Z7NHPUSyzmlDqQ2S8M pepesQYckE5smEdD5g1VtHDA0RWVic82758b1BteujpB7Xak230Fodu49U6YQ7zqWNag O6xA== X-Gm-Message-State: AHYfb5gHEmrv8X4axXG/M4QnYwE9LaCywzsUkIdVAPZureFr18WFGwCz WQlxVhA2nBAlwWEWgod2Dg== X-Received: by 10.28.63.13 with SMTP id m13mr4937749wma.63.1503596741436; Thu, 24 Aug 2017 10:45:41 -0700 (PDT) Original-Received: from ?IPv6:2a02:c7d:51cb:c700:e8f6:5609:eba7:e5e? ([2a02:c7d:51cb:c700:e8f6:5609:eba7:e5e]) by smtp.gmail.com with ESMTPSA id 27sm5930391wru.62.2017.08.24.10.45.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 10:45:40 -0700 (PDT) In-Reply-To: <83lgm89a1v.fsf@gnu.org> Content-Language: en-GB 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:136157 Archived-At: On 24/08/17 17:59, Eli Zaretskii wrote: >> From: Reuben Thomas >> Date: Wed, 23 Aug 2017 11:59:41 +0100 >> >> I now understand the two meanings of "multibyte", but I don't understa= nd >> how my patch is deficient. > I didn't say it was deficient, Sorry, I was unclear. I meant, precisely, I don't see why you think my patch's code returns a string that is not multibyte. > I asked whether you verified that > either (a) the result is always multibyte I believe I showed this is the case. > >> So in fact even when the string isn't copied (as in my patch, where I >> also use a third argument of t to decode-coding-string) it appears to = be >> changed to a multibyte string. > Fine, if you are sure, go ahead and push. > 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") =3D> nil > > but > > (multibyte-string-p (decode-coding-string "abcd" 'utf-8)) =3D> t In other words: 1. As far as I can tell from the above (and my own confirmatory experiments and reading of the documentation), a pure ASCII string can be multibyte (it's a matter of the multibyte flag, not the number of bytes used to store each character). 2. decode-coding-string always returns a multibyte string. Since these two observations seemed to mean that you contradicted yourself, I was checking whether in fact I had misunderstood (so that for example one of my two observations above is wrong), or if your original understanding was incomplete (so that in fact your question about decode-coding-string is therefore misguided, because it can return a pure ASCII unibyte string (in the coding sense) which is nonetheless a multibyte string (in the sense that multibyte-string-p on it returns t). Sorry about the miscommunication. In any case, I think the code is correct, your original question was misguided, and I shall push, with, as Noam requested in another message, an explanation of my assumptions. No need to reply further unless you think there really is a problem! --=20 https://rrt.sc3d.org