From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler 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 19:13:32 +0100 Message-ID: <2511c498-1e36-07b2-b9b8-5849902cd416@daniel-mendler.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22011"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52459@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 13 19:14:34 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 1mwpqM-0005WE-25 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Dec 2021 19:14:34 +0100 Original-Received: from localhost ([::1]:33420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwpqK-0007RR-A0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Dec 2021 13:14:32 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwppq-00076L-TP for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:14:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45174) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mwppq-0002uG-Fk for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mwppq-0000rU-2w for bug-gnu-emacs@gnu.org; Mon, 13 Dec 2021 13:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2021 18:14:02 +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.16394192243272 (code B ref 52459); Mon, 13 Dec 2021 18:14:02 +0000 Original-Received: (at 52459) by debbugs.gnu.org; 13 Dec 2021 18:13:44 +0000 Original-Received: from localhost ([127.0.0.1]:56719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwppX-0000qh-TB for submit@debbugs.gnu.org; Mon, 13 Dec 2021 13:13:44 -0500 Original-Received: from server.qxqx.de ([178.63.65.180]:36867 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwppV-0000qI-CL for 52459@debbugs.gnu.org; Mon, 13 Dec 2021 13:13:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ES7ZMoP0sRWRBL5ZhrEuWeRQH2axNFrzU47IhoN0Lxs=; b=Ajtn7Vu+/jCkc16AKMf4STjhet LXaeHMPUXmSi10ud0fhcbmOqZT0tR7TMmG6vXVTswne+2L25/FAvGKfNl0em1c4K7aoi9B8pw0+VO RQhT6eZOW1B5evsOLw7EICArkNECEze6M/lp/HyeWW8aOH/KtsnVgvqGpclWCdz+bc5I=; In-Reply-To: <83wnk8l9ha.fsf@gnu.org> Content-Language: en-US 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:222334 Archived-At: > 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. > 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. > For 2), we now have in Emacs 29 the glyphless-display-mode, whereby > the bidi control characters are shown as small boxes with their > acronyms (RLE, FSI, PDI, etc.). Is that satisfactory? If not, why > not? The `glyphless-display-mode` would be a possible workaround if I just pass on the characters unescaped. However I want to produce strings which I can possibly copy to source code buffers. This is not possible if the strings are not escaped and contain the problematic control characters in literal form. Once again - I propose the addition of configuration variables which configure `prin1-string` to produce output where all control characters are escaped. I would even argue that current variable `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* or we could even further and add `print-escape-glyphless-characters` which would treat the same characters as `glyphless-display-mode`.