From unknown Sat Sep 13 02:51:30 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55777 <55777@debbugs.gnu.org> To: bug#55777 <55777@debbugs.gnu.org> Subject: Status: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' Reply-To: bug#55777 <55777@debbugs.gnu.org> Date: Sat, 13 Sep 2025 09:51:30 +0000 retitle 55777 [PATCH] Improve documentation of `string-to-multibyte', `stri= ng-to-unibyte' reassign 55777 emacs submitter 55777 Richard Hansen severity 55777 minor tag 55777 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 03 02:20:46 2022 Received: (at submit) by debbugs.gnu.org; 3 Jun 2022 06:20:46 +0000 Received: from localhost ([127.0.0.1]:55018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx0fu-0002LU-2B for submit@debbugs.gnu.org; Fri, 03 Jun 2022 02:20:46 -0400 Received: from lists.gnu.org ([209.51.188.17]:52710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx0fr-0002LM-UM for submit@debbugs.gnu.org; Fri, 03 Jun 2022 02:20:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx0fq-0001IH-Dx for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2022 02:20:42 -0400 Received: from spork.scientician.org ([66.228.35.160]:40344) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx0fo-0002Eu-Px for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2022 02:20:42 -0400 X-Submitted: to spork.scientician.org (Postfix) with ESMTPSA id 16A1B486D7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-spork; t=1654237240; bh=WwkpsuPai9Sd5yUcfw49aUD5HJhj/dCSGs9TSlPUdok=; h=Date:From:Subject:To:From; b=sTwU4zx6AUGf2epxrRGlUhhkYg4TaiOO9hNclaMQO/n1vOGCWEHC8eWYPX6nv4wI/ sOj64IfRYyP6U7FVgOYO5KIiNfTijswPcA52eP4p7/a8L0YYaQC58MHa6ffBXqGKba xNOUFgo2vhFuBph1Ce4cO6fyRoZKvYaTDUNpuAt4= X-Submitted: to mail.scientician.org (Postfix) with ESMTPSA id EED36201B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-mail; t=1654237239; bh=WwkpsuPai9Sd5yUcfw49aUD5HJhj/dCSGs9TSlPUdok=; h=Date:From:Subject:To:From; b=I0t85Hh22KiUxu9XRLUXTPJSX+Gs1o5FQfsnItF2cG+buUWKNXL5GTfH4fbsn+elP 5kS9cuCHabVG7WgaUFrU8Kvi/3h55eI1FZ9J5+2UWdk4HpZSHi+d7cD5aEwECWD7tk ekpTDtUWrzSANwELS6BCkWA2Tr/QuWzrVLNhaE6A= Message-ID: Date: Fri, 3 Jun 2022 02:20:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 From: Richard Hansen Subject: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' To: bug-gnu-emacs@gnu.org Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vBwsLrEgMv58EM4pRV1rHgdO" Received-SPF: pass client-ip=66.228.35.160; envelope-from=rhansen@rhansen.org; helo=spork.scientician.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vBwsLrEgMv58EM4pRV1rHgdO Content-Type: multipart/mixed; boundary="------------eXG2rN8Fo1rYVYRKL9uhEqKa"; protected-headers="v1" From: Richard Hansen To: bug-gnu-emacs@gnu.org Message-ID: Subject: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' --------------eXG2rN8Fo1rYVYRKL9uhEqKa Content-Type: multipart/mixed; boundary="------------fqf1rZNj1QxR0oK6S9wn5wGA" --------------fqf1rZNj1QxR0oK6S9wn5wGA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 U2VlIGF0dGFjaGVkLg0K --------------fqf1rZNj1QxR0oK6S9wn5wGA Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-documentation-of-string-to-multibyte-string-.patch" Content-Disposition: attachment; filename*0="0001-Improve-documentation-of-string-to-multibyte-string-.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSAyZTBlOTQ0ODQwZGU2NTkzNmE5NzliMDc1YWEyZWE0MTc3ZjQ5ODU0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIEhhbnNlbiA8cmhhbnNlbkByaGFuc2Vu Lm9yZz4KRGF0ZTogRnJpLCAzIEp1biAyMDIyIDAxOjA0OjQxIC0wNDAwClN1YmplY3Q6IFtQ QVRDSF0gSW1wcm92ZSBkb2N1bWVudGF0aW9uIG9mIGBzdHJpbmctdG8tbXVsdGlieXRlJywK IGBzdHJpbmctdG8tdW5pYnl0ZScKCiogZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aSAoQ29u dmVydGluZyBSZXByZXNlbnRhdGlvbnMpOiBGaXgKZXJyb25lb3VzIGRlc2NyaXB0aW9uIG9m IGBzdHJpbmctdG8tdW5pYnl0ZScgKGl0IGRvZXMgbm90IHNpZ25hbCBhbgplcnJvciBvbiBl aWdodC1iaXQgY2hhcmFjdGVycykgYW5kIGNsYXJpZnkgaXRzIGJlaGF2aW9yLiBVcGRhdGUK ZG9jdW1lbnRhdGlvbiBvZiBgc3RyaW5nLXRvLW11bHRpYnl0ZScgdG8gbWF0Y2guCi0tLQog ZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aSB8IDI0ICsrKysrKysrKysrKysrLS0tLS0tLS0t LQogMSBmaWxlIGNoYW5nZWQsIDE0IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQoK ZGlmZiAtLWdpdCBhL2RvYy9saXNwcmVmL25vbmFzY2lpLnRleGkgYi9kb2MvbGlzcHJlZi9u b25hc2NpaS50ZXhpCmluZGV4IGQ3ZDI1ZGMzNmEuLjg3NDZiNzlkZTggMTAwNjQ0Ci0tLSBh L2RvYy9saXNwcmVmL25vbmFzY2lpLnRleGkKKysrIGIvZG9jL2xpc3ByZWYvbm9uYXNjaWku dGV4aQpAQCAtMjcxLDIwICsyNzEsMjQgQEAgQ29udmVydGluZyBSZXByZXNlbnRhdGlvbnMK IEBkZWZ1biBzdHJpbmctdG8tbXVsdGlieXRlIHN0cmluZwogVGhpcyBmdW5jdGlvbiByZXR1 cm5zIGEgbXVsdGlieXRlIHN0cmluZyBjb250YWluaW5nIHRoZSBzYW1lIHNlcXVlbmNlCiBv ZiBjaGFyYWN0ZXJzIGFzIEB2YXJ7c3RyaW5nfS4gIElmIEB2YXJ7c3RyaW5nfSBpcyBhIG11 bHRpYnl0ZSBzdHJpbmcsCi1pdCBpcyByZXR1cm5lZCB1bmNoYW5nZWQuICBUaGUgZnVuY3Rp b24gYXNzdW1lcyB0aGF0IEB2YXJ7c3RyaW5nfQotaW5jbHVkZXMgb25seSBAYWNyb255bXtB U0NJSX0gY2hhcmFjdGVycyBhbmQgcmF3IDgtYml0IGJ5dGVzOyB0aGUKLWxhdHRlciBhcmUg Y29udmVydGVkIHRvIHRoZWlyIG11bHRpYnl0ZSByZXByZXNlbnRhdGlvbiBjb3JyZXNwb25k aW5nCi10byB0aGUgY29kZXBvaW50cyBAY29kZXsjeDNGRkY4MH0gdGhyb3VnaCBAY29kZXsj eDNGRkZGRn0sIGluY2x1c2l2ZQotKEBweHJlZntUZXh0IFJlcHJlc2VudGF0aW9ucywgY29k ZXBvaW50c30pLgoraXQgaXMgcmV0dXJuZWQgdW5jaGFuZ2VkLiAgT3RoZXJ3aXNlLCBieXRl IHZhbHVlcyBAY29kZXsjeDAwfSB0aHJvdWdoCitAY29kZXsjeDdGfSAoQGFjcm9ueW17QVND SUl9IGNoYXJhY3RlcnMpIGFyZSBtYXBwZWQgdG8gdGhlaXIKK2NvcnJlc3BvbmRpbmcgY29k ZXBvaW50cywgYW5kIGJ5dGUgdmFsdWVzIEBjb2RleyN4ODB9IHRocm91Z2gKK0Bjb2RleyN4 RkZ9IChlaWdodC1iaXQgY2hhcmFjdGVycykgYXJlIG1hcHBlZCB0byBjb2RlcG9pbnRzCitA Y29kZXsjeDNGRkY4MH0gdGhyb3VnaCBAY29kZXsjeDNGRkZGRn0gKEBweHJlZntUZXh0IFJl cHJlc2VudGF0aW9ucywKK2NvZGVwb2ludHN9KS4KIEBlbmQgZGVmdW4KIAogQGRlZnVuIHN0 cmluZy10by11bmlieXRlIHN0cmluZwogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGEgdW5pYnl0 ZSBzdHJpbmcgY29udGFpbmluZyB0aGUgc2FtZSBzZXF1ZW5jZSBvZgotY2hhcmFjdGVycyBh cyBAdmFye3N0cmluZ30uICBJdCBzaWduYWxzIGFuIGVycm9yIGlmIEB2YXJ7c3RyaW5nfQot Y29udGFpbnMgYSBub24tQGFjcm9ueW17QVNDSUl9IGNoYXJhY3Rlci4gIElmIEB2YXJ7c3Ry aW5nfSBpcyBhCi11bmlieXRlIHN0cmluZywgaXQgaXMgcmV0dXJuZWQgdW5jaGFuZ2VkLiAg VXNlIHRoaXMgZnVuY3Rpb24gZm9yCi1AdmFye3N0cmluZ30gYXJndW1lbnRzIHRoYXQgY29u dGFpbiBvbmx5IEBhY3Jvbnlte0FTQ0lJfSBhbmQgZWlnaHQtYml0Ci1jaGFyYWN0ZXJzLgor Y2hhcmFjdGVycyBhcyBAdmFye3N0cmluZ30uICBJZiBAdmFye3N0cmluZ30gaXMgYSB1bmli eXRlIHN0cmluZywgaXQKK2lzIHJldHVybmVkIHVuY2hhbmdlZC4gIE90aGVyd2lzZSwgY29k ZXBvaW50cyBAY29kZXsjeDAwfSB0aHJvdWdoCitAY29kZXsjeDdGfSAoQGFjcm9ueW17QVND SUl9IGNoYXJhY3RlcnMpIGFyZSBtYXBwZWQgdG8gdGhlaXIKK2NvcnJlc3BvbmRpbmcgYnl0 ZSB2YWx1ZXMsIGFuZCBjb2RlcG9pbnRzIEBjb2RleyN4M0ZGRjgwfSB0aHJvdWdoCitAY29k ZXsjeDNGRkZGRn0gKGVpZ2h0LWJpdCBjaGFyYWN0ZXJzKSBhcmUgbWFwcGVkIHRvIGJ5dGUg dmFsdWVzCitAY29kZXsjeDgwfSB0aHJvdWdoIEBjb2RleyN4RkZ9IChAcHhyZWZ7VGV4dCBS ZXByZXNlbnRhdGlvbnMsCitjb2RlcG9pbnRzfSkuICBJdCBzaWduYWxzIGFuIGVycm9yIGlm IGFueSBvdGhlciBjb2RlcG9pbnQgaXMKK2VuY291bnRlcmVkLgogQGVuZCBkZWZ1bgogCiBA ZGVmdW4gYnl0ZS10by1zdHJpbmcgYnl0ZQotLSAKMi4zNi4xCgo= --------------fqf1rZNj1QxR0oK6S9wn5wGA-- --------------eXG2rN8Fo1rYVYRKL9uhEqKa-- --------------vBwsLrEgMv58EM4pRV1rHgdO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfoCctB7fyOzE09bW0GvrRa1X4hQFAmKZqDMACgkQ0GvrRa1X 4hS7RxAAszfKNhYCRAly4R/3OmhmtwynXm3e41+kt0t711tcyIQLAF345Ky9PY2P EEPbmNJiYg+h4AQM10p9FGxR+uzJQ9a7MLnUhC6FZ22rkloHEn8xPP2Nr3uxBAab V+sUFYTk218rraJ7Jde/lBcG7aVmEwlgKt4Z0zwzVViQn8YsuVZ4T+SkB9clqUGD z/epOEBKigQQ4YgIIYZrRK74K6R4CCgPMgOJHrfXjASX8FiD6H6Gzg3W7GT7/erW yPA6xnQLWWXPrrcSSrP4jm02p2gIHog3n7QVOg9dPllqn9hSRjsPnsCJmvy62Y7Z SpSBtgNCP/CtT5Mfb+AWJ9B+Eecf2W1wke0tM7EncXNHCe3PreeESAw/2MZ2MeIb 4pYVdyRH1V/0J7NkTWsXEfiRzbNmIhfbw4Mr0q7KIq2AJ2h4WEgsG3h9LF32RORw BUvFdYE/wK8k3ZGInBClL6Vt4Yw1w27P3e7x5mDkjUBd+0CzcBRYCQ2hSJgYiR8g TcVC6hVr99bZfP0e0Y8VWX10S0jrGi4S3LAO7qm9MDUegrzDeZWmUEwjLegMzgZ5 oe/X1EdrjC/l7G5VJUrU4grAxIbQ0VHW/usraGsEDjjD7WW3iiCOlGyM0jCESI3G b3UFI9oX+9fzbSy76l6DuOsLEjIv/otnRElFAzrLLHio5ymtrNo= =YafL -----END PGP SIGNATURE----- --------------vBwsLrEgMv58EM4pRV1rHgdO-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 03 03:02:19 2022 Received: (at 55777) by debbugs.gnu.org; 3 Jun 2022 07:02:19 +0000 Received: from localhost ([127.0.0.1]:55139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx1K7-0005d9-Jr for submit@debbugs.gnu.org; Fri, 03 Jun 2022 03:02:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx1K2-0005cs-5R for 55777@debbugs.gnu.org; Fri, 03 Jun 2022 03:02:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx1Jw-000431-SP; Fri, 03 Jun 2022 03:02:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RsIj/9wwGlyOWmPOU21eb7zf2cFpmBM+c6c1qzGbRxg=; b=HIRuuznOJwk5 ot795+88I7MtRlMgnjTHEjbuVkCGqQrss8JoN+7XwEiEU7pvbCaniztE5LxFZTvlyikiHPqLyTB7Y xNxG9rs1Dl2e9RflyVVsZXLN0xa4XPNYymrVXeVI+8L8+6eExP+J/n/y6gCR0BtOV88j1HucpTyc3 y2EpBk66mF2zoL72rFn4vaKjzWGGw7lkoBTbxIlGKtnMC44Aw3jaTdPs4/LxlInWrO8wtk9QVP0Qj HOiBt5evPOfb0Aa1/Cn9SjfbrXX8muZgvjkAaUS2YmprmSki9429c89sM8kv3HK+eR2FVF83JJhkG X6kIjN0OpFHecI2PP7xXbg==; Received: from [87.69.77.57] (port=2153 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx1Jw-0002z2-A1; Fri, 03 Jun 2022 03:02:08 -0400 Date: Fri, 03 Jun 2022 10:02:20 +0300 Message-Id: <83sfomcjr7.fsf@gnu.org> From: Eli Zaretskii To: Richard Hansen In-Reply-To: (message from Richard Hansen on Fri, 3 Jun 2022 02:20:35 -0400) Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 3 Jun 2022 02:20:35 -0400 > From: Richard Hansen > > See attached. Thanks, but please explain the motivation for these changes. In particular, why would we need to describe in a doc string such intimate details of our current implementation? If there was some situation where you needed these details for some Lisp program, please describe that situation. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 03 23:29:00 2022 Received: (at 55777) by debbugs.gnu.org; 4 Jun 2022 03:29:00 +0000 Received: from localhost ([127.0.0.1]:57329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxKTE-0007Fh-1d for submit@debbugs.gnu.org; Fri, 03 Jun 2022 23:29:00 -0400 Received: from spork.scientician.org ([66.228.35.160]:55280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxKTB-0007FY-94 for 55777@debbugs.gnu.org; Fri, 03 Jun 2022 23:28:58 -0400 X-Submitted: to spork.scientician.org (Postfix) with ESMTPSA id 4893F486D7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-spork; t=1654313336; bh=cllDI2FtWRm1abl1Kt7SC+hFwEPgk6Xua43t2kiEoFM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=UVbHdVxJVyd6x4/kojsFLVDyfwbcE5yjhec/h96yg7ZcsNqb8XFuEOxGD5cSJaDAV iGeevlISAsnH1+Ief09G2MoamBU20sCS6eqkPQ7DhjUn2BOauidKT02V6HdTB0OLov EmKT+gVRrl8LqxlNuSTUUAL6ZBfd2C/I8y9gwtwI= X-Submitted: to mail.scientician.org (Postfix) with ESMTPSA id 89D5B201B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-mail; t=1654313334; bh=cllDI2FtWRm1abl1Kt7SC+hFwEPgk6Xua43t2kiEoFM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CKAYEHLO2lCIkrRwoqzs6zFBPDkjfPeWKSk+bbgJtA7NRCsAbrynt+2IiSsdpaHVl N3pNURUIb67ihXqwEYdHJTf9naffaLEqJDsFVZdPvZSDxebIZiXPOdTQLVH1dRuGfh vt2h5u1YR7qfJOkKq+Ej1P4FDojp5c17v7ZIDJBg= Message-ID: Date: Fri, 3 Jun 2022 23:28:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' Content-Language: en-US To: Eli Zaretskii References: <83sfomcjr7.fsf@gnu.org> From: Richard Hansen In-Reply-To: <83sfomcjr7.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------TmTX0BUZAZVlCrFVwOqh4lPD" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TmTX0BUZAZVlCrFVwOqh4lPD Content-Type: multipart/mixed; boundary="------------8u8ye0D02JuxUFT4DL4fLRY0"; protected-headers="v1" From: Richard Hansen To: Eli Zaretskii Cc: 55777@debbugs.gnu.org Message-ID: Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: <83sfomcjr7.fsf@gnu.org> In-Reply-To: <83sfomcjr7.fsf@gnu.org> --------------8u8ye0D02JuxUFT4DL4fLRY0 Content-Type: multipart/mixed; boundary="------------SCpJrpz3RjxgRAdIpKyt0891" --------------SCpJrpz3RjxgRAdIpKyt0891 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gNi8zLzIyIDAzOjAyLCBFbGkgWmFyZXRza2lpIHdyb3RlOg0KPiBUaGFua3MsIGJ1dCBw bGVhc2UgZXhwbGFpbiB0aGUgbW90aXZhdGlvbiBmb3IgdGhlc2UgY2hhbmdlcy4NCg0KVGhl IG1vdGl2YXRpb24gaXMgaW4gdGhlIGNvbW1pdCBtZXNzYWdlLCB3aGljaCBJIHJldmlzZWQg aW4gdGhlDQphdHRhY2hlZCBwYXRjaCB0byBob3BlZnVsbHkgbWFrZSBpdCBtb3JlIGNsZWFy Lg0KDQo+IEluIHBhcnRpY3VsYXIsIHdoeSB3b3VsZCB3ZSBuZWVkIHRvIGRlc2NyaWJlIGlu IGEgZG9jIHN0cmluZyBzdWNoIA0KPiBpbnRpbWF0ZSBkZXRhaWxzIG9mIG91ciBjdXJyZW50 IGltcGxlbWVudGF0aW9uPw0KVGhlcmUgaXMgYSBmYWlyIGFtb3VudCBvZiBpbXBsZW1lbnRh dGlvbiBkZXRhaWwgcmlnaHQgbm93OyB0aGUgcGF0Y2gNCmRvZXNuJ3Qgc2lnbmlmaWNhbnRs eSBjaGFuZ2UgdGhhdC4gQnV0IEkgcmV2aXNlZCB0aGUgcGF0Y2ggdG8gcmVtb3ZlDQpzb21l IG9mIHRoZSBkZXRhaWwuDQoNCj4gSWYgdGhlcmUgd2FzIHNvbWUgc2l0dWF0aW9uIHdoZXJl IHlvdSBuZWVkZWQgdGhlc2UgZGV0YWlscyBmb3Igc29tZSANCj4gTGlzcCBwcm9ncmFtLCBw bGVhc2UgZGVzY3JpYmUgdGhhdCBzaXR1YXRpb24uDQpJJ20gdHJ5aW5nIHRvIHVuZGVyc3Rh bmQgc29tZSBpbmNvbnNpc3RlbnQgYmVoYXZpb3IgSSdtIG9ic2VydmluZw0Kd2hpbGUgd3Jp dGluZyBjb2RlIHRvIHByb2Nlc3MgYmluYXJ5IGRhdGEsIGFuZCBJIGZvdW5kIHRoZSBleGlz dGluZw0KZG9jdW1lbnRhdGlvbiBsYWNraW5nLg0KDQogICAgIDs7IFVuaWJ5dGUgdnMuIG11 bHRpYnl0ZSBjaGFyYWN0ZXJzOg0KICAgICAoZXEgP1x4ZmYgP1x4M2ZmZmZmKSAgICAgICAg ICAgICAgICAgICAgICAgICAgIDsgdCAob2spDQogICAgIChlcSAoYXJlZiAiXHgzZmZmZmYi IDApIChhcmVmICJceGZmIiAwKSkgICAgICAgOyB0IChvaykNCiAgICAgKGVxIChhcmVmICJc eDNmZmZmZiDwn5iAIiAwKSAoYXJlZiAiXHhmZiDwn5iAIiAwKSkgOyB0IChvaykNCiAgICAg KGVxIChhcmVmICJceGZmIiAwKSAoYXJlZiAiXHhmZiDwn5iAIiAwKSkgICAgICAgIDsgbmls IChleHBlY3RlZCB0KQ0KDQogICAgIDs7IFVuaWJ5dGUgdnMuIG11bHRpYnl0ZSBzdHJpbmdz Og0KICAgICAobXVsdGlieXRlLXN0cmluZy1wICJceGZmIikgICAgICAgICAgICAgICAgICAg IDsgbmlsIChvaykNCiAgICAgKG11bHRpYnl0ZS1zdHJpbmctcCAiXHgzZmZmZmYiKSAgICAg ICAgICAgICAgICA7IG5pbCAob2s/Pz8pDQogICAgIChzdHJpbmc9ICJceGZmIiAoc3RyaW5n LXRvLW11bHRpYnl0ZSAiXHhmZiIpKSAgOyBuaWwgKGV4cGVjdGVkIHQpDQoNCiAgICAgOzsg Q2hhciBjb2RlIHZzLiBVbmljb2RlIGNvZGVwb2ludDoNCiAgICAgKHN0cmluZz0gIvCfmIBc eGZmIiAi8J+YgFx4M2ZmZmZmIikgICAgICAgICAgICAgICAgOyB0IChvaykNCiAgICAgKHN0 cmluZz0gIvCfmIBcTntVK2ZmfSIgIvCfmIBceGZmIikgICAgICAgICAgICAgICAgOyBuaWwg KG9rKQ0KICAgICAoc3RyaW5nPSAi8J+YgFxOe1UrZmZ9IiAi8J+YgFx4M2ZmZmZmIikgICAg ICAgICAgICA7IG5pbCAob2spDQogICAgIChzdHJpbmc9ICLwn5iAw78iICLwn5iAXE57VStm Zn0iKSAgICAgICAgICAgICAgICAgICA7IHQgKG9rKQ0KICAgICAoc3RyaW5nPSAi8J+YgMO/ IiAi8J+YgFx4ZmYiKSAgICAgICAgICAgICAgICAgICAgICAgOyBuaWwgKG9rKQ0KICAgICAo c3RyaW5nPSAi8J+YgMO/IiAi8J+YgFx4M2ZmZmZmIikgICAgICAgICAgICAgICAgICAgOyBu aWwgKG9rKQ0KICAgICAoZXEgP1xOe1UrZmZ9ID9ceGZmKSAgICAgICAgICAgICAgICAgICAg ICAgICAgIDsgdCAoZXhwZWN0ZWQgbmlsKQ0KICAgICAoZXEgP1xOe1UrZmZ9ID9ceDNmZmZm ZikgICAgICAgICAgICAgICAgICAgICAgIDsgdCAoZXhwZWN0ZWQgbmlsKQ0KICAgICAoZXEg P8O/ID9ceGZmKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IHQgKGV4cGVj dGVkIG5pbCkNCiAgICAgKGVxID/DvyA/XHgzZmZmZmYpICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgOyB0IChleHBlY3RlZCBuaWwpDQo= --------------SCpJrpz3RjxgRAdIpKyt0891 Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-documentation-of-string-to-multibyte-string-.patch" Content-Disposition: attachment; filename*0="0001-Improve-documentation-of-string-to-multibyte-string-.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA2ODEzYjBhNDMyNTBjOTYzM2Q4NGQ3MjQxODkwNDAyNWU5NzNmMWM4IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIEhhbnNlbiA8cmhhbnNlbkByaGFuc2Vu Lm9yZz4KRGF0ZTogRnJpLCAzIEp1biAyMDIyIDAxOjA0OjQxIC0wNDAwClN1YmplY3Q6IFtQ QVRDSF0gSW1wcm92ZSBkb2N1bWVudGF0aW9uIG9mIGBzdHJpbmctdG8tbXVsdGlieXRlJywK IGBzdHJpbmctdG8tdW5pYnl0ZScKCiogZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aSAoQ29u dmVydGluZyBSZXByZXNlbnRhdGlvbnMpOiBSZW1vdmUKY29uZnVzaW5nIHNlbnRlbmNlIGZy b20gYHN0cmluZy10by1tdWx0aWJ5dGUnIGRvY3VtZW50YXRpb24gKGJ5CmRlZmluaXRpb24g dW5pYnl0ZSBzdHJpbmdzIGNhbiBvbmx5IGNvbnRhaW4gQVNDSUkgYW5kIGVpZ2h0LWJpdApj aGFyYWN0ZXJzLCBzbyB0aGVyZSdzIG5vIG5lZWQgdG8gYXNzdW1lIHRoYXQgdW5pYnl0ZSBz dHJpbmdzIG9ubHkKY29udGFpbiB0aG9zZSBjaGFyYWN0ZXJzKS4gIEZpeCBkZXNjcmlwdGlv biBvZiB0aGUgY2hhcmFjdGVycyB0aGF0CndpbGwgY2F1c2UgYHN0cmluZy10by11bmlieXRl JyB0byBzaWduYWwgYW4gZXJyb3IgKGBlaWdodC1iaXQnCmNoYXJhY3RlcnMgYXJlIE9LKS4g IFJlbW92ZSBzb21lIGltcGxlbWVudGF0aW9uIGRldGFpbHMgdGhhdCBhcmUKZGlzY3Vzc2Vk IGluIHRoZSB4cmVmZWQgc2VjdGlvbi4gIFdvcmQgdGhlIGRvY3VtZW50YXRpb24gZm9yIHRo ZSB0d28KZnVuY3Rpb25zIHNpbWlsYXJseSBzbyB0aGF0IGl0IGlzIGNsZWFyIHRoZXkgYXJl IGludmVyc2VzIG9mIGVhY2gKb3RoZXIuCi0tLQogZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4 aSB8IDE5ICsrKysrKysrKy0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA5IGluc2VydGlv bnMoKyksIDEwIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RvYy9saXNwcmVmL25vbmFz Y2lpLnRleGkgYi9kb2MvbGlzcHJlZi9ub25hc2NpaS50ZXhpCmluZGV4IGQ3ZDI1ZGMzNmEu LmU4ZjAyZDhmMmYgMTAwNjQ0Ci0tLSBhL2RvYy9saXNwcmVmL25vbmFzY2lpLnRleGkKKysr IGIvZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aQpAQCAtMjcxLDIwICsyNzEsMTkgQEAgQ29u dmVydGluZyBSZXByZXNlbnRhdGlvbnMKIEBkZWZ1biBzdHJpbmctdG8tbXVsdGlieXRlIHN0 cmluZwogVGhpcyBmdW5jdGlvbiByZXR1cm5zIGEgbXVsdGlieXRlIHN0cmluZyBjb250YWlu aW5nIHRoZSBzYW1lIHNlcXVlbmNlCiBvZiBjaGFyYWN0ZXJzIGFzIEB2YXJ7c3RyaW5nfS4g IElmIEB2YXJ7c3RyaW5nfSBpcyBhIG11bHRpYnl0ZSBzdHJpbmcsCi1pdCBpcyByZXR1cm5l ZCB1bmNoYW5nZWQuICBUaGUgZnVuY3Rpb24gYXNzdW1lcyB0aGF0IEB2YXJ7c3RyaW5nfQot aW5jbHVkZXMgb25seSBAYWNyb255bXtBU0NJSX0gY2hhcmFjdGVycyBhbmQgcmF3IDgtYml0 IGJ5dGVzOyB0aGUKLWxhdHRlciBhcmUgY29udmVydGVkIHRvIHRoZWlyIG11bHRpYnl0ZSBy ZXByZXNlbnRhdGlvbiBjb3JyZXNwb25kaW5nCi10byB0aGUgY29kZXBvaW50cyBAY29kZXsj eDNGRkY4MH0gdGhyb3VnaCBAY29kZXsjeDNGRkZGRn0sIGluY2x1c2l2ZQotKEBweHJlZntU ZXh0IFJlcHJlc2VudGF0aW9ucywgY29kZXBvaW50c30pLgoraXQgaXMgcmV0dXJuZWQgdW5j aGFuZ2VkLiAgT3RoZXJ3aXNlLCBieXRlIHZhbHVlcyBhcmUgdHJhbnNmb3JtZWQgdG8KK3Ro ZWlyIGNvcnJlc3BvbmRpbmcgbXVsdGlieXRlIGNvZGVwb2ludHMgKEBhY3Jvbnlte0FTQ0lJ fSBjaGFyYWN0ZXJzCithbmQgY2hhcmFjdGVycyBpbiB0aGUgQGNvZGV7ZWlnaHQtYml0fSBj aGFyc2V0KS4gIEB4cmVme1RleHQKK1JlcHJlc2VudGF0aW9ucywgY29kZXBvaW50c30uCiBA ZW5kIGRlZnVuCiAKIEBkZWZ1biBzdHJpbmctdG8tdW5pYnl0ZSBzdHJpbmcKIFRoaXMgZnVu Y3Rpb24gcmV0dXJucyBhIHVuaWJ5dGUgc3RyaW5nIGNvbnRhaW5pbmcgdGhlIHNhbWUgc2Vx dWVuY2Ugb2YKLWNoYXJhY3RlcnMgYXMgQHZhcntzdHJpbmd9LiAgSXQgc2lnbmFscyBhbiBl cnJvciBpZiBAdmFye3N0cmluZ30KLWNvbnRhaW5zIGEgbm9uLUBhY3Jvbnlte0FTQ0lJfSBj aGFyYWN0ZXIuICBJZiBAdmFye3N0cmluZ30gaXMgYQotdW5pYnl0ZSBzdHJpbmcsIGl0IGlz IHJldHVybmVkIHVuY2hhbmdlZC4gIFVzZSB0aGlzIGZ1bmN0aW9uIGZvcgotQHZhcntzdHJp bmd9IGFyZ3VtZW50cyB0aGF0IGNvbnRhaW4gb25seSBAYWNyb255bXtBU0NJSX0gYW5kIGVp Z2h0LWJpdAotY2hhcmFjdGVycy4KK2NoYXJhY3RlcnMgYXMgQHZhcntzdHJpbmd9LiAgSWYg QHZhcntzdHJpbmd9IGlzIGEgdW5pYnl0ZSBzdHJpbmcsIGl0CitpcyByZXR1cm5lZCB1bmNo YW5nZWQuICBPdGhlcndpc2UsIEBhY3Jvbnlte0FTQ0lJfSBjaGFyYWN0ZXJzIGFuZAorY2hh cmFjdGVycyBpbiB0aGUgQGNvZGV7ZWlnaHQtYml0fSBjaGFyc2V0IGFyZSBjb252ZXJ0ZWQg dG8gdGhlaXIKK2NvcnJlc3BvbmRpbmcgYnl0ZSB2YWx1ZXMuICBJdCBzaWduYWxzIGFuIGVy cm9yIGlmIGFueSBvdGhlciBjaGFyYWN0ZXIKK2lzIGVuY291bnRlcmVkLiAgQHhyZWZ7VGV4 dCBSZXByZXNlbnRhdGlvbnMsIGNvZGVwb2ludHN9LgogQGVuZCBkZWZ1bgogCiBAZGVmdW4g Ynl0ZS10by1zdHJpbmcgYnl0ZQotLSAKMi4zNi4xCgo= --------------SCpJrpz3RjxgRAdIpKyt0891-- --------------8u8ye0D02JuxUFT4DL4fLRY0-- --------------TmTX0BUZAZVlCrFVwOqh4lPD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfoCctB7fyOzE09bW0GvrRa1X4hQFAmKa0XMACgkQ0GvrRa1X 4hQbGg//Wye7X86s+BLxVZWGTJBdhhRfF5MluJBf8R8ydb9yNpqtdb6LnlP5X1bf rZnTj7a1NLhQbmh6AUvZbM4EaDi/flPfeUxeOUr+sfDBRe1FYcfe5s5WDwO9t4fh tm+faC2Wy5xuANaImyNTfrC/8Jz+TPGSdyHGr9KaIzLlFPoP4QIVPD22oTg/lNXY 67p3ZPBYUCIaS371jywQyr/cdoR2AP1Q2jbiXHeGyusxPLw+cZ6B+BZ2/7vTeaMT oByN7sU3CWw5fmCvDukfJvkgryvBpuJNnsDQj5PChcdIvbxGDjLJz/ET5LK85Zkn vrE9SZz8xmjEg7m4pvKKGjfdJGhISLKIv7NuKoKEv7fpwCLOE0NA2RNPdTfkGAuF yl8W0c8647c33BpnDOqNBKK2IA9wJpl3qNEOMXBngkTBlte2wCu9+/33hgPxpGYa 6HzioyApBhSRW8B2WhLjVgE3mcV2KA6q2L8xVtxIrKISYSMyYEpUBZ/HQ2b9Zh6X ve3HpECrKKxHUQIfRhrqqPgOjnDp/DEL08yKuNCWR6WA7LNoQJvPKhZBQuvx9agm yopenAx+OxzVn1w+jkglIo9unC9JQjOx9annh84RE6zQLYtJA9HJ4f6YdEtAwenp NLqWFFslnSGGG/n6llYHKHvWAwqKwPXCnn+p4XhlqI9c8mEojV8= =/cKl -----END PGP SIGNATURE----- --------------TmTX0BUZAZVlCrFVwOqh4lPD-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 03:09:56 2022 Received: (at 55777) by debbugs.gnu.org; 4 Jun 2022 07:09:56 +0000 Received: from localhost ([127.0.0.1]:57530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxNv2-0004Z5-AC for submit@debbugs.gnu.org; Sat, 04 Jun 2022 03:09:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxNuy-0004Yl-21 for 55777@debbugs.gnu.org; Sat, 04 Jun 2022 03:09:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46198) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxNus-00009G-D7; Sat, 04 Jun 2022 03:09:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ITaF/gk5lVbG/9bmEi4cIT0c8biuM+zXJN3jZmNfnNc=; b=Cpx5UwM9b5JfHsytfUw9 Iq5Xy8g7x885KPh/6B0jZsQZIZ8BxC0LMjoE3QdkNlOMxv9x9EXUaDDDGn8iFzpk3Lj0kAdNW0F5P UJ8PeBjfNefyb515e9hEAWAEaWVsAa6jWdYoJKobVxbgD4TMwmz1Ez+noFJsnHUDIpEiyesJoG/0D MVo3QDpxxTA7lKHoB38n3MTluIoKMmhNJc+YK04dYgFI975q3j4beP9LCTLycaL70+kHeszqqYHdS klSMlpuT1QzXJlDEs8qq1+8HLzB/aWImtMIKNqRtrPLOOyk1A/OVSq6UYHFIKF/tfpjyJDxDZWIAg a+QMv7D1tYHVBg==; Received: from [87.69.77.57] (port=3781 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxNur-0001oR-Ok; Sat, 04 Jun 2022 03:09:46 -0400 Date: Sat, 04 Jun 2022 10:09:42 +0300 Message-Id: <83ilpgc3bd.fsf@gnu.org> From: Eli Zaretskii To: Richard Hansen In-Reply-To: (message from Richard Hansen on Fri, 3 Jun 2022 23:28:51 -0400) Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: <83sfomcjr7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 3 Jun 2022 23:28:51 -0400 > Cc: 55777@debbugs.gnu.org > From: Richard Hansen > > > If there was some situation where you needed these details for some > > Lisp program, please describe that situation. > I'm trying to understand some inconsistent behavior I'm observing > while writing code to process binary data, and I found the existing > documentation lacking. You are digging into low-level details of how Emacs keeps strings in memory, and the higher-level context of _why_ you need to understand these details is left untold. In general, Lisp programs are well advised to stay away of manipulating unibyte strings, and definitely to refrain from comparing unibyte and multibyte strings -- because these are supposed to be never needed in Lisp applications, and because doing TRT with those requires non-trivial knowledge of the Emacs internals. I see no reason to complicate the documentation for the very rare occasions where these issues unfortunately leak to higher-than-expected levels. > ;; Unibyte vs. multibyte characters: > (eq ?\xff ?\x3fffff) ; t (ok) > (eq (aref "\x3fffff" 0) (aref "\xff" 0)) ; t (ok) > (eq (aref "\x3fffff 😀" 0) (aref "\xff 😀" 0)) ; t (ok) > (eq (aref "\xff" 0) (aref "\xff 😀" 0)) ; nil (expected t) > > ;; Unibyte vs. multibyte strings: > (multibyte-string-p "\xff") ; nil (ok) > (multibyte-string-p "\x3fffff") ; nil (ok???) > (string= "\xff" (string-to-multibyte "\xff")) ; nil (expected t) > > ;; Char code vs. Unicode codepoint: > (string= "😀\xff" "😀\x3fffff") ; t (ok) > (string= "😀\N{U+ff}" "😀\xff") ; nil (ok) > (string= "😀\N{U+ff}" "😀\x3fffff") ; nil (ok) > (string= "😀ÿ" "😀\N{U+ff}") ; t (ok) > (string= "😀ÿ" "😀\xff") ; nil (ok) > (string= "😀ÿ" "😀\x3fffff") ; nil (ok) > (eq ?\N{U+ff} ?\xff) ; t (expected nil) > (eq ?\N{U+ff} ?\x3fffff) ; t (expected nil) > (eq ?ÿ ?\xff) ; t (expected nil) > (eq ?ÿ ?\x3fffff) ; t (expected nil) If you still don't understand some of these, please feel free to ask questions, and we will gladly answer them. But I see no reason to change the documentation on that behalf. > @@ -271,20 +271,19 @@ Converting Representations > @defun string-to-multibyte string > This function returns a multibyte string containing the same sequence > of characters as @var{string}. If @var{string} is a multibyte string, > -it is returned unchanged. The function assumes that @var{string} > -includes only @acronym{ASCII} characters and raw 8-bit bytes; the > -latter are converted to their multibyte representation corresponding > -to the codepoints @code{#x3FFF80} through @code{#x3FFFFF}, inclusive > -(@pxref{Text Representations, codepoints}). > +it is returned unchanged. Otherwise, byte values are transformed to > +their corresponding multibyte codepoints (@acronym{ASCII} characters > +and characters in the @code{eight-bit} charset). @xref{Text > +Representations, codepoints}. This loses information, so I don't think we should make this change. It might be trivially clear to you that unibyte string can only contain ASCII and raw bytes, but it isn't necessarily clear to everyone. > @defun string-to-unibyte string > This function returns a unibyte string containing the same sequence of > -characters as @var{string}. It signals an error if @var{string} > -contains a non-@acronym{ASCII} character. If @var{string} is a > -unibyte string, it is returned unchanged. Use this function for > -@var{string} arguments that contain only @acronym{ASCII} and eight-bit > -characters. > +characters as @var{string}. If @var{string} is a unibyte string, it > +is returned unchanged. Otherwise, @acronym{ASCII} characters and > +characters in the @code{eight-bit} charset are converted to their > +corresponding byte values. It signals an error if any other character > +is encountered. @xref{Text Representations, codepoints}. This basically rearranges the existing text, and adds just one sentence: Otherwise, @acronym{ASCII} characters and characters in the @code{eight-bit} charset are converted to their corresponding byte values. The cross-reference is identical to the one we already have a few lines above this text, so it is redundant. I've made a change to add the above sentence, and slightly rearranged the text to be more clear and logically complete. Here's how this text looks now on the emacs-28 branch (and will appear in Emacs 28.2 and later): @defun string-to-unibyte string This function returns a unibyte string containing the same sequence of characters as @var{string}. If @var{string} is a unibyte string, it is returned unchanged. Otherwise, @acronym{ASCII} characters and characters in the @code{eight-bit} charset are converted to their corresponding byte values. Use this function for @var{string} arguments that contain only @acronym{ASCII} and eight-bit characters; the function signals an error if any other characters are encountered. @end defun Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 20:16:56 2022 Received: (at 55777) by debbugs.gnu.org; 5 Jun 2022 00:16:56 +0000 Received: from localhost ([127.0.0.1]:59785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxdwt-0001Dj-Kz for submit@debbugs.gnu.org; Sat, 04 Jun 2022 20:16:56 -0400 Received: from spork.scientician.org ([66.228.35.160]:43954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxdwq-0001Db-S4 for 55777@debbugs.gnu.org; Sat, 04 Jun 2022 20:16:54 -0400 X-Submitted: to spork.scientician.org (Postfix) with ESMTPSA id 34DB44A1AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-spork; t=1654388212; bh=XkAlpU6Iz449nDYBSGjMBuicbxsXkk29IyM+qEayEM0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=UpCLErJAyELpFKT9kPs9VkyalZuw7BSJxlaBys8ucI2hNWa7flVzrmHxBX+l4BC1X za9jQJVUU+QT/3DskZ8H30D69zbzmblzfhg8h0zyJcFsD0qUzljR/Bf99F9rCEZlQr QV3bpQNQ3+tHlx3gwL4XfbooNeJDwGR9SUd0AYXw= X-Submitted: to mail.scientician.org (Postfix) with ESMTPSA id 67EC1201B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-mail; t=1654388210; bh=XkAlpU6Iz449nDYBSGjMBuicbxsXkk29IyM+qEayEM0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=sAWh3K5TPmAMl2nh0dOlLpiSdLw9sBzpWsWMS/rqnI8uOA15WJwx0dyEhGCcRxlWF TapGwW3LXeZ/aBUhSN04rrnWN59m0qVfXyaB/HmvOHRBqIbDDTKuzAsfXDtKD2BT+G WZlWZL8fM/HRfNGnTqWYaZlgLdCCKuHyPRzdCwBI= Message-ID: <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> Date: Sat, 4 Jun 2022 20:16:47 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' Content-Language: en-US To: Eli Zaretskii References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> From: Richard Hansen In-Reply-To: <83ilpgc3bd.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------HJ6Ii660ayi4oU5l4MaZoZQq" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HJ6Ii660ayi4oU5l4MaZoZQq Content-Type: multipart/mixed; boundary="------------yUXTSmMpnnHA3GbztppJPOmc"; protected-headers="v1" From: Richard Hansen To: Eli Zaretskii Cc: 55777@debbugs.gnu.org Message-ID: <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> In-Reply-To: <83ilpgc3bd.fsf@gnu.org> --------------yUXTSmMpnnHA3GbztppJPOmc Content-Type: multipart/mixed; boundary="------------bjxS0y9wK7iDndA09O6gZN00" --------------bjxS0y9wK7iDndA09O6gZN00 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gNi80LzIyIDAzOjA5LCBFbGkgWmFyZXRza2lpIHdyb3RlOg0KPj4+IElmIHRoZXJlIHdh cyBzb21lIHNpdHVhdGlvbiB3aGVyZSB5b3UgbmVlZGVkIHRoZXNlIGRldGFpbHMgZm9yIHNv bWUNCj4+PiBMaXNwIHByb2dyYW0sIHBsZWFzZSBkZXNjcmliZSB0aGF0IHNpdHVhdGlvbi4N Cj4+DQo+PiBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgc29tZSBpbmNvbnNpc3RlbnQgYmVo YXZpb3IgSSdtIG9ic2VydmluZw0KPj4gd2hpbGUgd3JpdGluZyBjb2RlIHRvIHByb2Nlc3Mg YmluYXJ5IGRhdGEsIGFuZCBJIGZvdW5kIHRoZSBleGlzdGluZw0KPj4gZG9jdW1lbnRhdGlv biBsYWNraW5nLg0KPiANCj4gWW91IGFyZSBkaWdnaW5nIGludG8gbG93LWxldmVsIGRldGFp bHMgb2YgaG93IEVtYWNzIGtlZXBzIHN0cmluZ3MgaW4NCj4gbWVtb3J5LCBhbmQgdGhlIGhp Z2hlci1sZXZlbCBjb250ZXh0IG9mIF93aHlfIHlvdSBuZWVkIHRvIHVuZGVyc3RhbmQNCj4g dGhlc2UgZGV0YWlscyBpcyBsZWZ0IHVudG9sZC4NCg0KUmVhZGVycyBlaXRoZXIgdGhpbmsg dGhlIGRvY3VtZW50YXRpb24gaXMgY29uZnVzaW5nIG9yIHRoZXkgZG9uJ3Q7IHdoeQ0KdGhl eSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGRvY3VtZW50YXRpb24gaXMgbW9zdGx5IGlycmVs ZXZhbnQuIEkNCmZpbmQgdGhlIGRvY3VtZW50YXRpb24gdG8gYmUgY29uZnVzaW5nLCBhbmQg SSBzdXNwZWN0IEkgYW0gbm90IHRoZQ0Kb25seSBvbmUuDQoNCj4gSW4gZ2VuZXJhbCwgTGlz cCBwcm9ncmFtcyBhcmUgd2VsbCBhZHZpc2VkIHRvIHN0YXkgYXdheSBvZg0KPiBtYW5pcHVs YXRpbmcgdW5pYnl0ZSBzdHJpbmdzLCBhbmQgZGVmaW5pdGVseSB0byByZWZyYWluIGZyb20g Y29tcGFyaW5nDQo+IHVuaWJ5dGUgYW5kIG11bHRpYnl0ZSBzdHJpbmdzIC0tIGJlY2F1c2Ug dGhlc2UgYXJlIHN1cHBvc2VkIHRvIGJlDQo+IG5ldmVyIG5lZWRlZCBpbiBMaXNwIGFwcGxp Y2F0aW9ucywgYW5kIGJlY2F1c2UgZG9pbmcgVFJUIHdpdGggdGhvc2UNCj4gcmVxdWlyZXMg bm9uLXRyaXZpYWwga25vd2xlZGdlIG9mIHRoZSBFbWFjcyBpbnRlcm5hbHMuDQoNCkkgZGlz YWdyZWUgd2l0aCAid2VsbCBhZHZpc2VkIi4gVGhlIGRvY3VtZW50YXRpb24gaW4gMzQuMSBh bmQgMzQuMw0KbWFrZSBpdCBzb3VuZCBsaWtlIHRoZSByZXByZXNlbnRhdGlvbiBpcyBtZXJl bHkgYW4gaW50ZXJuYWwgZWxpc3ANCmltcGxlbWVudGF0aW9uIGRldGFpbCB0aGF0IHByb2dy YW1tZXJzIGRvbid0IG5lZWQgdG8gd29ycnkgYWJvdXQsDQp1bmxlc3MgdGhleSBhcmUgZG9p bmcgc29tZXRoaW5nIHVudXN1YWxseSBsb3ctbGV2ZWwuDQoNCkkgY29uc2lkZXIgYmluYXJ5 IGRhdGEgcHJvY2Vzc2luZyB0byBiZSBzb21ld2hhdCBjb21tb24sIG5vdA0KInVudXN1YWxs eSBsb3ctbGV2ZWwiLiBZZXQgbWFuaXB1bGF0aW5nIGJ5dGUgdmFsdWVzIDEyOC0yNTUgaW4g dW5pYnl0ZQ0Kc3RyaW5ncywgYW5kIGNoYXJhY3RlcnMgd2l0aCBVbmljb2RlIGNvZGVwb2lu dHMgMTI4LTI1NSBpbiBtdWx0aWJ5dGUNCnN0cmluZ3MsIGlzIGZyYXVnaHQgd2l0aCBwZXJp bC4gRm9yIGV4YW1wbGUsIGl0IGlzIHJpc2t5IHRvIHVzZSBgYXJlZicNCnRvIHJlYWQgYSBj aGFyYWN0ZXIgb3IgYGFzZXQnIHRvIHdyaXRlIGEgY2hhcmFjdGVyIHVubGVzcyB5b3UgZWl0 aGVyDQprbm93IHRoZSBzdHJpbmcgcmVwcmVzZW50YXRpb24gb3Iga25vdyB0aGF0IHRoZSBj aGFyYWN0ZXIgaXMgbm90IGluDQojeDgwLSN4ZmYgb3IgI3gzZmZmODAtI3gzZmZmZmYuDQoN Cj4gDQo+IEkgc2VlIG5vIHJlYXNvbiB0byBjb21wbGljYXRlIHRoZSBkb2N1bWVudGF0aW9u IGZvciB0aGUgdmVyeSByYXJlDQo+IG9jY2FzaW9ucyB3aGVyZSB0aGVzZSBpc3N1ZXMgdW5m b3J0dW5hdGVseSBsZWFrIHRvDQo+IGhpZ2hlci10aGFuLWV4cGVjdGVkIGxldmVscy4NCg0K SSBkb24ndCB0aGluayB0aGUgb2NjYXNpb25zIGFyZSBhbGwgdGhhdCByYXJlLiAgQnV0IGV2 ZW4gaWYgdGhleSBhcmUsDQp0aGUgcHJlY2lzZSBiZWhhdmlvciBzaG91bGQgYmUgZG9jdW1l bnRlZCBzb21ld2hlcmUgc28gdGhhdA0KcHJvZ3JhbW1lcnMgd2hvIG5lZWQgbG93LWxldmVs IHN0cmluZyBtYW5pcHVsYXRpb24gY2FuIGRvIHNvDQpjb3JyZWN0bHkuICBJIHdvdWxkIGFy Z3VlIHRoYXQgcHJvZ3JhbW1lcnMgdXNpbmcgYHN0cmluZy10by11bmlieXRlJw0Kb3IgYHN0 cmluZy10by1tdWx0aWJ5dGUnIGZhbGwgaW50byB0aGF0IGNhdGVnb3J5Lg0KDQo+PiBAQCAt MjcxLDIwICsyNzEsMTkgQEAgQ29udmVydGluZyBSZXByZXNlbnRhdGlvbnMNCj4+ICAgQGRl ZnVuIHN0cmluZy10by1tdWx0aWJ5dGUgc3RyaW5nDQo+PiAgIFRoaXMgZnVuY3Rpb24gcmV0 dXJucyBhIG11bHRpYnl0ZSBzdHJpbmcgY29udGFpbmluZyB0aGUgc2FtZSBzZXF1ZW5jZQ0K Pj4gICBvZiBjaGFyYWN0ZXJzIGFzIEB2YXJ7c3RyaW5nfS4gIElmIEB2YXJ7c3RyaW5nfSBp cyBhIG11bHRpYnl0ZSBzdHJpbmcsDQo+PiAtaXQgaXMgcmV0dXJuZWQgdW5jaGFuZ2VkLiAg VGhlIGZ1bmN0aW9uIGFzc3VtZXMgdGhhdCBAdmFye3N0cmluZ30NCj4+IC1pbmNsdWRlcyBv bmx5IEBhY3Jvbnlte0FTQ0lJfSBjaGFyYWN0ZXJzIGFuZCByYXcgOC1iaXQgYnl0ZXM7IHRo ZQ0KPj4gLWxhdHRlciBhcmUgY29udmVydGVkIHRvIHRoZWlyIG11bHRpYnl0ZSByZXByZXNl bnRhdGlvbiBjb3JyZXNwb25kaW5nDQo+PiAtdG8gdGhlIGNvZGVwb2ludHMgQGNvZGV7I3gz RkZGODB9IHRocm91Z2ggQGNvZGV7I3gzRkZGRkZ9LCBpbmNsdXNpdmUNCj4+IC0oQHB4cmVm e1RleHQgUmVwcmVzZW50YXRpb25zLCBjb2RlcG9pbnRzfSkuDQo+PiAraXQgaXMgcmV0dXJu ZWQgdW5jaGFuZ2VkLiAgT3RoZXJ3aXNlLCBieXRlIHZhbHVlcyBhcmUgdHJhbnNmb3JtZWQg dG8NCj4+ICt0aGVpciBjb3JyZXNwb25kaW5nIG11bHRpYnl0ZSBjb2RlcG9pbnRzIChAYWNy b255bXtBU0NJSX0gY2hhcmFjdGVycw0KPj4gK2FuZCBjaGFyYWN0ZXJzIGluIHRoZSBAY29k ZXtlaWdodC1iaXR9IGNoYXJzZXQpLiAgQHhyZWZ7VGV4dA0KPj4gK1JlcHJlc2VudGF0aW9u cywgY29kZXBvaW50c30uDQo+IA0KPiBUaGlzIGxvc2VzIGluZm9ybWF0aW9uLCBzbyBJIGRv bid0IHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoaXMgY2hhbmdlLg0KPiBJdCBtaWdodCBiZSB0 cml2aWFsbHkgY2xlYXIgdG8geW91IHRoYXQgdW5pYnl0ZSBzdHJpbmcgY2FuIG9ubHkNCj4g Y29udGFpbiBBU0NJSSBhbmQgcmF3IGJ5dGVzLCBidXQgaXQgaXNuJ3QgbmVjZXNzYXJpbHkg Y2xlYXIgdG8NCj4gZXZlcnlvbmUuDQoNCkkgc3RpbGwgZmluZCB0aGUgY3VycmVudCB3b3Jk aW5nIHRvIGJlIGNvbmZ1c2luZy4gVG8gbWUsIGFsbCBieXRlcw0KaGF2ZSA4IGJpdHMgc28g InJhdyA4LWJpdCBieXRlcyIgc291bmRzIGJpemFycmVseSByZWR1bmRhbnQuIEFsc28sDQpB U0NJSSBjaGFyYWN0ZXJzIGFyZSBlbmNvZGVkIHRvIGJ5dGVzLCB5ZXQgInJhdyA4LWJpdCBi eXRlcyIgaXMgbWVhbnQNCnRvIHJlZmVyIG9ubHkgdG8gbm9uLUFTQ0lJIHZhbHVlcy4gSSBo YXZlIGF0dGFjaGVkIGFub3RoZXIgcmV2aXNpb24NCnRoYXQgSSB0aGluayBpcyBjb21wbGV0 ZSwgY29ycmVjdCwgYW5kIGVhc2llciB0byB1bmRlcnN0YW5kLg0KDQpUaGFua3MsDQpSaWNo YXJkDQo= --------------bjxS0y9wK7iDndA09O6gZN00 Content-Type: text/x-patch; charset=UTF-8; name="0001-Clarify-documentation-of-string-to-multibyte.patch" Content-Disposition: attachment; filename="0001-Clarify-documentation-of-string-to-multibyte.patch" Content-Transfer-Encoding: base64 RnJvbSAwZDc0ODEyMzkwNTZlMmQ3MDE1OTE3MjhmMjQwMDk0YzdhOTM5ZDNhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIEhhbnNlbiA8cmhhbnNlbkByaGFuc2Vu Lm9yZz4KRGF0ZTogRnJpLCAzIEp1biAyMDIyIDAxOjA0OjQxIC0wNDAwClN1YmplY3Q6IFtQ QVRDSF0gQ2xhcmlmeSBkb2N1bWVudGF0aW9uIG9mIGBzdHJpbmctdG8tbXVsdGlieXRlJwoK KiBkb2MvbGlzcHJlZi9ub25hc2NpaS50ZXhpIChDb252ZXJ0aW5nIFJlcHJlc2VudGF0aW9u cyk6IENsYXJpZnkKd2hhdCBgc3RyaW5nLXRvLW11bHRpYnl0ZScgZG9lcy4gIChCdWcjNTU3 NzcpCi0tLQogZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aSB8IDggKysrLS0tLS0KIDEgZmls ZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvZG9jL2xpc3ByZWYvbm9uYXNjaWkudGV4aSBiL2RvYy9saXNwcmVmL25vbmFzY2lpLnRl eGkKaW5kZXggNmRjMjM2MzdhNy4uN2EzYzNjNjNlNyAxMDA2NDQKLS0tIGEvZG9jL2xpc3By ZWYvbm9uYXNjaWkudGV4aQorKysgYi9kb2MvbGlzcHJlZi9ub25hc2NpaS50ZXhpCkBAIC0y NzEsMTEgKzI3MSw5IEBAIENvbnZlcnRpbmcgUmVwcmVzZW50YXRpb25zCiBAZGVmdW4gc3Ry aW5nLXRvLW11bHRpYnl0ZSBzdHJpbmcKIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBhIG11bHRp Ynl0ZSBzdHJpbmcgY29udGFpbmluZyB0aGUgc2FtZSBzZXF1ZW5jZQogb2YgY2hhcmFjdGVy cyBhcyBAdmFye3N0cmluZ30uICBJZiBAdmFye3N0cmluZ30gaXMgYSBtdWx0aWJ5dGUgc3Ry aW5nLAotaXQgaXMgcmV0dXJuZWQgdW5jaGFuZ2VkLiAgVGhlIGZ1bmN0aW9uIGFzc3VtZXMg dGhhdCBAdmFye3N0cmluZ30KLWluY2x1ZGVzIG9ubHkgQGFjcm9ueW17QVNDSUl9IGNoYXJh Y3RlcnMgYW5kIHJhdyA4LWJpdCBieXRlczsgdGhlCi1sYXR0ZXIgYXJlIGNvbnZlcnRlZCB0 byB0aGVpciBtdWx0aWJ5dGUgcmVwcmVzZW50YXRpb24gY29ycmVzcG9uZGluZwotdG8gdGhl IGNvZGVwb2ludHMgQGNvZGV7I3gzRkZGODB9IHRocm91Z2ggQGNvZGV7I3gzRkZGRkZ9LCBp bmNsdXNpdmUKLShAcHhyZWZ7VGV4dCBSZXByZXNlbnRhdGlvbnMsIGNvZGVwb2ludHN9KS4K K2l0IGlzIHJldHVybmVkIHVuY2hhbmdlZC4gIE90aGVyd2lzZSwgYnl0ZXMgd2l0aCB2YWx1 ZXMgMTI4IHRvIDI1NSBhcmUKK2NvbnZlcnRlZCB0byB0aGVpciBjb3JyZXNwb25kaW5nIG11 bHRpYnl0ZSByZXByZXNlbnRhdGlvbnMgaW4gdGhlCitAY29kZXtlaWdodC1iaXR9IGNoYXJz ZXQuCiBAZW5kIGRlZnVuCiAKIEBkZWZ1biBzdHJpbmctdG8tdW5pYnl0ZSBzdHJpbmcKLS0g CjIuMzYuMQoK --------------bjxS0y9wK7iDndA09O6gZN00-- --------------yUXTSmMpnnHA3GbztppJPOmc-- --------------HJ6Ii660ayi4oU5l4MaZoZQq Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfoCctB7fyOzE09bW0GvrRa1X4hQFAmKb9fAACgkQ0GvrRa1X 4hTnAQ/9EG694+LYNMoQa8ce1ao2D5IILTOWJjnEmHK/rU/9ubSEjNHoxmmzMSzs JQSpxt+UgYDsLOf7YIXmfNJltdLCPqKkbob9ti6bBa3E994BRUyYZsqbGvn4wNZn BST/0EYhxyR6YfbV/24mlMqBMshxibTDpREyBSwOfJXiT06rmkd27+szc6T7q50n w+6Irti8VoQMDBroeqWS5lzmAkiPIyXbnHpQHOJXMSgmkRuwh/CLzuBVgacC0shF xzMKFBvCTguWwODJXuqX2WycgmYOGDRjSaBzf+p5y+jf8PAUY5Fo5FIf3mtl18cc 9U8jK0LoZtF5CLUlNq8FoGo5KlNIzcqyNBjy3g1lK0D2/Fd9/8P3tlwSQ5+bxnuC GI7xEDSquSR65Ox3sXZw3nk1z5M0bHI9kzp6vop9J5+ex8oj2I8OEzXHf2oU95FU FWFloRpqygbD2uGqUcaa3ShC5BkhUtA9K3o3I2BfnJ79jg4JebILXwmhL6ZGQdRH mrRtpD7hRaesX/RmerdtfUu3kDiDAzhfyY63k0UGVdtu/NfIT5PFZ2zBz14BWq9I dykrlYcEXJ/6KXMYxIHFfuxV08DiR3vXFfc0SC0Aam4RxCnOCwgpZ/3k+pK0OxcK ISxQxArTf7aNMcEi3RJOrlFEqLPwDJzr1GubsXWKlkJFpoczCsA= =4pbo -----END PGP SIGNATURE----- --------------HJ6Ii660ayi4oU5l4MaZoZQq-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 05 01:37:53 2022 Received: (at 55777) by debbugs.gnu.org; 5 Jun 2022 05:37:53 +0000 Received: from localhost ([127.0.0.1]:59940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxixV-0001On-Fy for submit@debbugs.gnu.org; Sun, 05 Jun 2022 01:37:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nxixS-0001OZ-UP for 55777@debbugs.gnu.org; Sun, 05 Jun 2022 01:37:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38640) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxixM-0004Jn-If; Sun, 05 Jun 2022 01:37:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BkwBl+VLJ+YCWdKEcSu5PprBosUqHcHPEiDO2B0LtjM=; b=bamFdi74Q6zh 4xKSOSAgN4x8ciMILAgPdW0weC6++vbn+u8qQo2beNO7TPDiLzilqpsjjU7CmD7ZVC+iFWxPF0xv9 yeczvS7peiSg/GTnvwDz5W0xK4n+pbqGfqRe4WWN2qN14gaIgO2GXiDd+3thoG1uAxQ41vsNjqWJg E0iDfklANQcrrbJ3q0yQuSASs3DYONeuW/u1xm9F40nEhyt8zFLD9Qk4Alh84hiP6HIIUminC4cUd 0lsnqtdMsC8vfB9qSDpMulTw4ZAVvPuQ8SWzDnlyHsaqJeCQiUo09sB2y+lhlBeL12RcGYrF8jsar 40pZNaRq6PEOV4B52IEsBw==; Received: from [87.69.77.57] (port=4457 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxixD-0008W8-EY; Sun, 05 Jun 2022 01:37:44 -0400 Date: Sun, 05 Jun 2022 08:37:16 +0300 Message-Id: <83zgiracxf.fsf@gnu.org> From: Eli Zaretskii To: Richard Hansen In-Reply-To: <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> (message from Richard Hansen on Sat, 4 Jun 2022 20:16:47 -0400) Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 4 Jun 2022 20:16:47 -0400 > Cc: 55777@debbugs.gnu.org > From: Richard Hansen > > > You are digging into low-level details of how Emacs keeps strings in > > memory, and the higher-level context of _why_ you need to understand > > these details is left untold. > > Readers either think the documentation is confusing or they don't; why > they need to understand the documentation is mostly irrelevant. I > find the documentation to be confusing, and I suspect I am not the > only one. I said "understand the details", not "understand the documentation". The latter is a no-brainer: documentation should be understandable, and I don't think what we have now isn't. See below regarding the parts you say confused you. > > In general, Lisp programs are well advised to stay away of > > manipulating unibyte strings, and definitely to refrain from comparing > > unibyte and multibyte strings -- because these are supposed to be > > never needed in Lisp applications, and because doing TRT with those > > requires non-trivial knowledge of the Emacs internals. > > I disagree with "well advised". The documentation in 34.1 and 34.3 > make it sound like the representation is merely an internal elisp > implementation detail that programmers don't need to worry about, > unless they are doing something unusually low-level. That is exactly the intent. The recommendation not to deal with non-text data directly (as opposed via, say, packages like bindat.el) is based on experience, both mine and that of others. > I consider binary data processing to be somewhat common, not > "unusually low-level". Yet manipulating byte values 128-255 in unibyte > strings, and characters with Unicode codepoints 128-255 in multibyte > strings, is fraught with peril. For example, it is risky to use `aref' > to read a character or `aset' to write a character unless you either > know the string representation or know that the character is not in > #x80-#xff or #x3fff80-#x3fffff. You are describing some of the known difficulties that arise when manipulating binary data in Emacs strings and buffers, which are the reasons for the above recommendation. Emacs can do all this, but not easily, since it isn't its main design goal. For comparison, some other text-processing environments simply reject any non-character data in strings. > > I see no reason to complicate the documentation for the very rare > > occasions where these issues unfortunately leak to > > higher-than-expected levels. > > I don't think the occasions are all that rare. But even if they are, > the precise behavior should be documented somewhere so that > programmers who need low-level string manipulation can do so > correctly. Documenting every aspect of the Emacs behavior for the rare chance that someone some day will find it useful would make our documentation too large. The Emacs Lisp Reference manual already prints in 2 very thick volumes. So our policy is not to document the aspects that are too obscure to be useful to many. > I would argue that programmers using `string-to-unibyte' > or `string-to-multibyte' fall into that category. I disagree. First, these functions should be used very rarely, and we generally try to avoid them entirely. And if they do need to be used, the current documentation is IMO adequate. It still has to be understandable, of course, but it doesn't need to describe every possible detail of how Emacs handles raw bytes and conversions between them and readable text. > I still find the current wording to be confusing. To me, all bytes > have 8 bits so "raw 8-bit bytes" sounds bizarrely redundant. Also, > ASCII characters are encoded to bytes, yet "raw 8-bit bytes" is meant > to refer only to non-ASCII values. What are "raw bytes" is explained in one of the previous sections of this chapter. > I have attached another revision that I think is complete, correct, > and easier to understand. I think it muddies the water by talking about numerical values 128 to 255, which also match some Latin characters. It also removes the reference to the codepoints Emacs uses to represent these bytes, which is important in some situations. So I think your proposal would change this text for the worse. Could you please state what is confusing in the current wording? If it's only the "raw 8-bit bytes" thing, it is explained earlier in the manual; if needed, we could add a cross-reference there to that section. If it's something else, please tell. But mentioning the single-byte numerical values here actually increases the confusion, IME, due to overlap with valid Unicode codepoints, which is why we should and do deliberately refrain from doing that. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 05 22:00:41 2022 Received: (at 55777) by debbugs.gnu.org; 6 Jun 2022 02:00:41 +0000 Received: from localhost ([127.0.0.1]:33973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ny22r-0001h4-3s for submit@debbugs.gnu.org; Sun, 05 Jun 2022 22:00:41 -0400 Received: from spork.scientician.org ([66.228.35.160]:43586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ny22o-0001gv-CL for 55777@debbugs.gnu.org; Sun, 05 Jun 2022 22:00:39 -0400 X-Submitted: to spork.scientician.org (Postfix) with ESMTPSA id B43AB47F45 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-spork; t=1654480837; bh=6uqPSomrDCgKRfW72BuLXrA+iJ63fmMQqFzVlJcLSPM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eFhHDkfQnvPd0gDOXS364a/6lt0jD0L99Tlen6jj31Y3vubTTWrmL08AULsPH8Xfz /8svUsJ4RS3Z28odSujwQmQjJGbIzemOC8+EHWMIyJuiY0rUwm3yKFYiF3neJJjolT xiUZGrXCBIPiz8stlmQW049BBA05gFSXxMMulCyU= X-Submitted: to mail.scientician.org (Postfix) with ESMTPSA id A9422201AF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhansen.org; s=20130902-mail; t=1654480834; bh=6uqPSomrDCgKRfW72BuLXrA+iJ63fmMQqFzVlJcLSPM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=yO6OqEY9QDYX65R8UB1loHeHe9d6o3zV1n6/lgROJQRsql8JMs1jSJ29UYe2ROHlQ rInaa6gu5cZpgYZv3hNgZeLhbymkyVDD0NuKYfqFjXuPdoxS+WpA5fVyekkPyT1S+6 69AhchOke2f1c9X/ebLdsvktKUXBRcvmyf8NyRuo= Message-ID: <16ed6ce6-725f-a183-8864-7e9185b14ff4@rhansen.org> Date: Sun, 5 Jun 2022 22:00:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' Content-Language: en-US To: Eli Zaretskii References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> <83zgiracxf.fsf@gnu.org> From: Richard Hansen In-Reply-To: <83zgiracxf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 6/5/22 01:37, Eli Zaretskii wrote: > Could you please state what is confusing in the current wording? * "Raw 8-bit bytes" isn't really defined. It's mentioned earlier in the chapter -- the term is even in a @dfn{} -- but there's no definition there. * The term "raw 8-bit bytes" is misleading. It suggests binary data (bytes with values 0-255) but it's actually meant to only cover 128-255. * The term "raw 8-bit bytes" is not used consistently. Sometimes "8" is spelled out as "eight", sometimes "raw" comes after "8-bit", and sometimes it refers to all byte values 0-255 (see the first sentence under `@cindex unibyte text`). * It's not clear whether "raw 8-bit bytes" is meant to refer to bytes with values 128-255, or to the *characters* that map to those byte values. * The following phrasing is weird: "The function assumes that @var{string} includes ASCII characters and raw 8-bit bytes". The purpose of "raw 8-bit bytes" is to cover non-ASCII byte values, so by definition that assumption is always true. By saying "the function assumes", the reader is left wondering about the cases where that assumption is not true, which in turn causes the reader to question whether "raw 8-bit bytes" fully covers non-ASCII byte values, which in turn causes the reader to wonder how to handle those non-covered values (whatever they are). Maybe something like this: By definition, unibyte strings contain only @acronym{ASCII} characters (bytes with values 0-127) and raw 8-bit bytes (bytes with values 128-255); the latter are converted to their corresponding multibyte representations in the @code{eight-bit} character set (@pxref{Text Representations, codepoints}). From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 06 07:29:42 2022 Received: (at 55777) by debbugs.gnu.org; 6 Jun 2022 11:29:42 +0000 Received: from localhost ([127.0.0.1]:34524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyAvV-0002ON-RM for submit@debbugs.gnu.org; Mon, 06 Jun 2022 07:29:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyAvS-0002Ny-Tn for 55777@debbugs.gnu.org; Mon, 06 Jun 2022 07:29:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyAvN-0000Mn-Ij; Mon, 06 Jun 2022 07:29:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=+5ClX2qqUErDidK0lXiD47oymOGFxVEWyfHK3BeSQMg=; b=jacweLZzXQjKQmvikkVK t0n7kvGZYaHj6GEGg8UYHJcW4GjV7ZptuNqGQ3MuehmWNo9O92xfPnmlBsb46iwAbYY2o5ZG/CQy+ Ui0HgzPxEhT16LTKHN8j9ZGz9GpKq4eY1uLMJxmsJOJpODAghVgKAu1NaudKzlJj9A4gzqIwE1RfP bogzhwf1TtfS58or1ft81IjELDh5niTsTmDAIVaFhs+xnraDheucttxJzmmPtXwgjJVvcuwvTuAA5 AZUm63IPL4xFULNjgX97ykUL9KYZ7keSPylKgz+q4K5hfWhvlMPnVo19yMCejMAhyuXZVhuT4637J 6djiaAro2RRwKw==; Received: from [87.69.77.57] (port=3745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyAvL-0000yW-Ds; Mon, 06 Jun 2022 07:29:33 -0400 Date: Mon, 06 Jun 2022 14:29:19 +0300 Message-Id: <83fski81yo.fsf@gnu.org> From: Eli Zaretskii To: Richard Hansen In-Reply-To: <16ed6ce6-725f-a183-8864-7e9185b14ff4@rhansen.org> (message from Richard Hansen on Sun, 5 Jun 2022 22:00:35 -0400) Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> <83zgiracxf.fsf@gnu.org> <16ed6ce6-725f-a183-8864-7e9185b14ff4@rhansen.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55777 Cc: 55777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 5 Jun 2022 22:00:35 -0400 > Cc: 55777@debbugs.gnu.org > From: Richard Hansen > > On 6/5/22 01:37, Eli Zaretskii wrote: > > Could you please state what is confusing in the current wording? > > * "Raw 8-bit bytes" isn't really defined. It's mentioned earlier in > the chapter -- the term is even in a @dfn{} -- but there's no > definition there. It is defined as best we could without confusing the readers: Occasionally, Emacs needs to hold and manipulate encoded text or binary non-text data in its buffers or strings. For example, when Emacs visits a file, it first reads the file’s text verbatim into a buffer, and only then converts it to the internal representation. Before the conversion, the buffer holds encoded text. Encoded text is not really text, as far as Emacs is concerned, but rather a sequence of raw 8-bit bytes. We call buffers and strings that hold encoded text “unibyte” buffers and strings, because Emacs treats them as a sequence of individual bytes. [...] (The @dfn part is markup used whenever new terminology is first used, it doesn't imply "definition".) You are welcome to propose a better explanation, but one thing is a non-starter: mentioning the numerical codes of those bytes, certainly as part of their "definition". This is because their numerical codes overlap Latin characters, and people were very confused about that when we mentioned them in the documentation in the past. So now we deliberately don't mention the values. The definition is effectively "bytes that have no meaning as human-readable text". > * The term "raw 8-bit bytes" is misleading. It suggests binary data > (bytes with values 0-255) but it's actually meant to only cover > 128-255. It indeed could potentially mislead. But not necessarily: it is customary to use "eight-bit" to mean "with the 8th bit set". Once again, you don't have to convince me that this area is confusing and notoriously hard to document. The challenge is to come up with something that is better than what we have and yet doesn't trigger confusion which we already had in the past. > * The term "raw 8-bit bytes" is not used consistently. Sometimes "8" > is spelled out as "eight", sometimes "raw" comes after "8-bit", > and sometimes it refers to all byte values 0-255 (see the first > sentence under `@cindex unibyte text`). I see no problem here, none at all. This is a manual, not a mathematical treatise. > * It's not clear whether "raw 8-bit bytes" is meant to refer to > bytes with values 128-255, or to the *characters* that map to > those byte values. We specifically say they are NOT characters. From the above-cited description: Encoded text is not really text, as far as Emacs is concerned, but rather a sequence of raw 8-bit bytes. > * The following phrasing is weird: "The function assumes that > @var{string} includes ASCII characters and raw 8-bit bytes". The > purpose of "raw 8-bit bytes" is to cover non-ASCII byte values, so > by definition that assumption is always true. No, it isn't true "by definition". We are trying to make it very clear that we distinguish between "characters" and "raw bytes". "Characters" are units of human-readable text, and each character has a set of attributes that Emacs uses when processing text. Characters have letter-case, general category, directionality, numerical value, etc. By contrast, "raw bytes" don't have any such attributes: it is meaningless to ask whether a given raw byte is upper- or lower-case, or if its directionality is right-to-left, etc. I hope you now better understand what the sentence above attempts to say; it doesn't say things that are trivially true. > By saying "the > function assumes", the reader is left wondering about the cases > where that assumption is not true, Those other cases are multibyte strings, of course. We could add that in parentheses, e.g.: The function assumes that @var{string} includes ASCII characters and raw 8-bit bytes (as opposed to multibyte text). > Maybe something like this: > > By definition, unibyte strings contain only @acronym{ASCII} > characters (bytes with values 0-127) and raw 8-bit bytes > (bytes with values 128-255); the latter are converted to their > corresponding multibyte representations in the > @code{eight-bit} character set (@pxref{Text Representations, > codepoints}). As I tried to explain above, using the numerical codes of the bytes is a step backward: we've been there and done that, and found that people get confused by that, because the byte codes overlap the Unicode codepoints of Latin characters. Explaining the difference rigorously is IME impossible without delving into the internal representation of each one of them, since that is how Emacs _really_ distinguishes between them. But having all that in the ELisp Reference manual is completely unjustified (let alone not future-proof, since the internal representation can change). Another problem with the above text is that it implies ASCII characters are bytes: we don't want to call them that, to maintain the fundamental difference between characters and bytes. Yet another problem there is that you can have a multibyte string that is pure-ASCII, so "by definition" is also problematic. Bottom line: I think the manual describes this reasonably well, and, given the past experience, any change will have to be tangibly better before we make it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 19:21:25 2022 Received: (at 55777-done) by debbugs.gnu.org; 17 Aug 2022 23:21:25 +0000 Received: from localhost ([127.0.0.1]:53276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOSLl-0000aY-Fn for submit@debbugs.gnu.org; Wed, 17 Aug 2022 19:21:25 -0400 Received: from mail-vs1-f51.google.com ([209.85.217.51]:37749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOSLg-0000aH-Oz for 55777-done@debbugs.gnu.org; Wed, 17 Aug 2022 19:21:23 -0400 Received: by mail-vs1-f51.google.com with SMTP id z185so5107666vsb.4 for <55777-done@debbugs.gnu.org>; Wed, 17 Aug 2022 16:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:mime-version:user-agent:references :in-reply-to:from:from:to:cc; bh=iTh7ZgHCo5R79edNp8mq4yLr3ULIfT9jIR2/3hQiOVw=; b=S5tqB+BCBakHVVvBK+lAeZ0xHrMm8dzgkutYJdf7KtCIWFaa6CynEDVelRwURO8faI DK2xM4lNdS4OHRJFZwHIgT4HlwL0mLe6meTpalZCeNkZeLun8Rya5HGdtoMERto1XRhP hvvd+6VzyekjlVY4vGr/GZb7DKA4oBZUzIAhxEDMLe7OQi/obBBT5iU+DNMQnsd945oD AnpWI2xyvcQlXYVJlbjhJjs2p4W5fS12eQ0oHc+7OHxo9aHTXXDfhKAY/Y+2NzuOUyke /el6g7Qw+oh68l9i7cMh/cvFLCLC2R5Xfwh/aVmVP3SrgKdPqtX2OT+CxuATB5skUUMF 6zHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:mime-version:user-agent:references :in-reply-to:from:x-gm-message-state:from:to:cc; bh=iTh7ZgHCo5R79edNp8mq4yLr3ULIfT9jIR2/3hQiOVw=; b=dMiEobWJ2xL+lu4uRwV06qM+GFRExNVVmtoZAWNhjQLC8ZExmNz3XwhBZF5/guZQ7N f7wkojZPL3YnFVklLMm/o6vxgofDW6Jk0LNQU63EG54stE7nnurDGNBAUi6M5bC9Z6GS LmKlliyTlWylA2jTPs64TAfZno+f7Ppu8Jj8cpwOn2kLV6hxeE+zKFK2ozLPEhPJpOFg 0yUbxnbTAXJ8l6BdqQMLBoXcUuBv6Joqa9zBfLzMpymS95oVG0hIs7J+XsGJMroLcKvc TrpFmyTZ0dS/7oPJNmkok24XHgYfzz1R+SrTCtOOhkg5SDz5hlmvWdluwQPmSGGCokav T+BQ== X-Gm-Message-State: ACgBeo0/Hfje9GUt3sXQ9lkWm21Iu2C/0nD5x7EZN+eE/dl8Xt+LbIJS 8Os+ztDFCVN5KvCBhkCXMeQN7K/kM388F+f9uQ8= X-Google-Smtp-Source: AA6agR6WRJmjvuNS0jvrpxVs1+djUzJ7rnZCdt6PFDadxYfTI46f6VJn9lMfX7cIdVWdefJeGexlhsFlnFvFvPEkjAk= X-Received: by 2002:a67:efd6:0:b0:388:4860:9bda with SMTP id s22-20020a67efd6000000b0038848609bdamr88080vsp.46.1660778475103; Wed, 17 Aug 2022 16:21:15 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Aug 2022 16:21:14 -0700 From: Stefan Kangas In-Reply-To: <83fski81yo.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Jun 2022 14:29:19 +0300") References: <83sfomcjr7.fsf@gnu.org> <83ilpgc3bd.fsf@gnu.org> <1c6f61d2-80df-38ab-a895-f73ad4be63a7@rhansen.org> <83zgiracxf.fsf@gnu.org> <16ed6ce6-725f-a183-8864-7e9185b14ff4@rhansen.org> <83fski81yo.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) X-Hashcash: 1:20:220817:eliz@gnu.org::1uiNk4996C8pLmy6:1qL6 MIME-Version: 1.0 Date: Wed, 17 Aug 2022 16:21:14 -0700 Message-ID: Subject: Re: bug#55777: [PATCH] Improve documentation of `string-to-multibyte', `string-to-unibyte' To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 55777-done Cc: 55777-done@debbugs.gnu.org, Richard Hansen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Bottom line: I think the manual describes this reasonably well, and, > given the past experience, any change will have to be tangibly better > before we make it. No further comments within 10 weeks, but it sounds like the conclusion here is that we don't want to make the suggested changes. I'm therefore closing this bug report. From unknown Sat Sep 13 02:51:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 15 Sep 2022 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator