From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-26 8f18d12: Improve documentation of decoding into a unibyte buffer Date: Tue, 28 May 2019 21:58:03 +0300 Message-ID: <83muj6z9s4.fsf@gnu.org> References: <20190525191039.14136.23307@vcs0.savannah.gnu.org> <20190525191040.CCD6C207F5@vcs0.savannah.gnu.org> <88F01F35-BE24-4F6E-B832-64AFE28CD06B@gnu.org> <83woiazjyo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35875"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 28 20:58:18 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVhIf-0009CT-Go for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 20:58:17 +0200 Original-Received: from localhost ([127.0.0.1]:41135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVhIe-0002ai-0L for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 14:58:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVhIV-0002ad-9q for emacs-devel@gnu.org; Tue, 28 May 2019 14:58:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37312) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVhIL-0004Yt-Hg; Tue, 28 May 2019 14:57:59 -0400 Original-Received: from [176.228.60.248] (port=1348 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hVhIJ-0004ei-4H; Tue, 28 May 2019 14:57:55 -0400 In-reply-to: (message from Stefan Monnier on Tue, 28 May 2019 13:43:47 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237122 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Tue, 28 May 2019 13:43:47 -0400 > > > (let* ((str1 (string-as-multibyte (string char))) > > (str2 (string-as-multibyte (string char char))) > > Why on earth do we call string-as-multibyte here? AFAIK, the only cases > where `string` returns a unibyte string is when char <128 (it could make > sense to also do that for char ≥128 and <160, but we don't seem to do > that currently) and these are better turned into multibyte via > string-TO-unibyte (tho here we don't even need that, since the unibyte > string works just as well for what we do) than string-AS-unibyte. > > I think this is an error. The patch below seems in order. I'm not sure. Be sure to read the comments about the tricky business of this function, and the method it employs to solve it, and be sure you understand all of the subtleties there. > > I didn't think enough about this to figure out if there can be less > > trivial use cases. If you can describe all the cases where > > find-coding-systems-string will return a list whose 'car' is > > 'undecided', my hat off to you. > > AFAIK it only happens for pure-ASCII strings. What is your reasoning?