From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#52459: 28.0.90; prin1-to-string does not escape bidi control characters despite print-escape-control-characters=t Date: Mon, 13 Dec 2021 20:28:10 +0200 Message-ID: <83tufcl5qd.fsf@gnu.org> References: <83v8ztmu75.fsf@gnu.org> <93d63756-f75d-c53e-de02-2e8270d07311@daniel-mendler.de> <83r1agn184.fsf@gnu.org> <0eabc668-ecb2-8f77-17cf-f9cb6dcf0626@daniel-mendler.de> <0504d4a8-1a4b-a451-d7d3-fea1c116b96d@daniel-mendler.de> <8335mwmssm.fsf@gnu.org> <7027aad4-d156-12ae-7356-4d55be5716b1@daniel-mendler.de> <83wnk8l9ha.fsf@gnu.org> <2511c498-1e36-07b2-b9b8-5849902cd416@daniel-mendler.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30654"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52459@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 13 19:29:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mwq4Y-0007ik-FK for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Dec 2021 19:29:14 +0100 Original-Received: from localhost ([::1]:36880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwq4W-0002U7-As for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Dec 2021 13:29:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwq4M-0002Tn-CF for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:29:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45180) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mwq4M-0005aU-3B for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mwq4L-0001CU-Sj for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2021 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52459 X-GNU-PR-Package: emacs Original-Received: via spool by 52459-submit@debbugs.gnu.org id=B52459.16394201384605 (code B ref 52459); Mon, 13 Dec 2021 18:29:01 +0000 Original-Received: (at 52459) by debbugs.gnu.org; 13 Dec 2021 18:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:56726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwq48-0001C3-95 for submit@debbugs.gnu.org; Mon, 13 Dec 2021 13:28:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwq43-0001Bl-1E for 52459@debbugs.gnu.org; Mon, 13 Dec 2021 13:28:46 -0500 Original-Received: from [2001:470:142:3::e] (port=39762 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwq3x-0005T9-Az; Mon, 13 Dec 2021 13:28:37 -0500 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=MLrj23F5dcUlymYoBSpGLoUCUbeA1Q8IVNahB/zCz+I=; b=VlJ/te9wbcbc TVPxWOe2PTforl1kjTHddGw078awziKFplHieBMnez/Gu8VzxOhVadKTuu8fj/Hgn6gikrL6mn0Q4 p3pV6bkyX0feUjYzXPwhWHwWRiVn0lzTZxf48whhI9kEzcfwZw4YWMHIJN5THPdKvsOzzaiamQ1VE nCENt/JEejPBNVUats2oTqdgZZrU8uI2l43+kggBt1AMmhQzuF5tDMPex0BSB7VdRrLzex5vEjeND 1WIOggu1tiZABzl82Z0cjyXXqZfOEgLkZ263zWGRxvq66nahmCRmxjMMPdLL6H4nCesB32UQJSGR9 NR7BsKjTxLm7FCzbVfzILA==; Original-Received: from [87.69.77.57] (port=3458 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 1mwq3v-0006sy-3b; Mon, 13 Dec 2021 13:28:37 -0500 In-Reply-To: <2511c498-1e36-07b2-b9b8-5849902cd416@daniel-mendler.de> (message from Daniel Mendler on Mon, 13 Dec 2021 19:13:32 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:222335 Archived-At: > Cc: 52459@debbugs.gnu.org > From: Daniel Mendler > Date: Mon, 13 Dec 2021 19:13:32 +0100 > > > 1) produce strings for using in program source files. > > 2) produce strings for display in various UIs > > > > The solutions should IMO be different, because the first is not about > > displaying these characters, while the second is about displaying > > them. > > No, they are not different for my purposes since I want to have the > ability to copy strings from the UI to a source file. Working around the > problem on the display level (glyphless-display-mode) will preclude this > use case. But in the debug UI use-case, you do want to see the text and be able to read it, don't you? Which is why you said you don't want to have escapes there, you want to see characters. Which means that use-case is about _displaying_ these characters, not _replacing_ them with something else. And you _cannot_ copy anything that only exists on display, because that copies the actual codepoints, not their visual representation. > > For 1), is print-escape-multibyte satisfactory? If not, why not? > > I already explained this. `print-escape-multibyte` obfuscates the string > too much, which is undesirable for a debugging UI. Note that I am > passing on this experience report from a Russian user who observed that > Marginalia (which currently uses `print-escape-multibyte=t`) produces > output which is not as helpful as it could be thanks to the escaping of > all multi byte characters. The escaping hurts users of multi-byte languages. The use case you describe with Marginalia is of a different kind -- why do they use print-escape-multibyte in that case? Cyrillic text doesn't use bidi controls, so what does that use case have to do with your request? What I'm suggesting is to use print-escape-multibyte when producing strings for inclusion in the source code, and only for that purpose. You, OTOH, are talking about case 2), where these strings are presented in a UI. Then of course print-escape-multibyte is inappropriate for that. > Once again - I propose the addition of configuration variables which > configure `prin1-string` to produce output where all control characters > are escaped. That could help in case 1), but not in case 2), because there prin1 is not used, or not necessarily used. > `print-escape-control-characters` is misleading since it only encodes > Ascii control characters. Is there anything which prevents the addition > of a configuration variable `print-escape-unicode-control-characters`, > which ensures full escaping of *all control characters* Escaping where? on display? That won't help you to write strings as in bidi-directional-controls-chars. I thought this was one part of your request? But I already said that, and so it sounds like we have some grave misunderstanding that I'm unable to resolve. So maybe it's time for someone else to try. Sorry I couldn't be of more help.