unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Mendler <mail@daniel-mendler.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 52459@debbugs.gnu.org
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 14:19:00 +0100	[thread overview]
Message-ID: <0eabc668-ecb2-8f77-17cf-f9cb6dcf0626@daniel-mendler.de> (raw)
In-Reply-To: <83r1agn184.fsf@gnu.org>

> Sorry, I don't understand.  The examples you provided are of text
> being displayed.  Which is expected, since these controls have no
> other effect _except_ when the text is displayed.  So why isn't the
> existing function bidi-string-mark-left-to-right (which was introduced
> precisely for the situations like you describe, and is actually used
> in Emacs for those purposes) the solution for the class of problems
> that you described?

`bidi-string-mark-left-to-right` is an insufficient solution since it
manipulates the string on the level of display properties. It appends an
invisible character. If I take the string returned by
`bidi-string-mark-left-to-right` I cannot manipulate it freely
afterwards. In particular if I truncate the string, the invisible
character will be lost again.

I need a function which sanitizes a string completely, such that after
sanitization I can use and manipulate it without having to worry about
display properties or other pecularities.

> And can we agree that displaying these characters as escapes would not
> solve the problems you had in mind, so it is off the table for the
> rest of this discussion?

No, I disagree. This should not be off the table. I don't understand why
you want to close this issue so quickly. The probem I described is an
actual problem, which I've observed in multiple packages. Ideally Emacs
would offer a solution on the API level such that package authors and
users can sanitize strings in a robust way. Such an API does not exist
currently.

Escaping all control characters is my preferred solution. What about
adding two variables: `print-escape-unicode-control-characters` and
`print-escape-ascii-control-characters`, such that it is explicit what
is going on? The variable `print-escape-control-characters` could be
deprecated or aliased to `print-escape-ascii-control-characters`.






  reply	other threads:[~2021-12-13 13:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-12 20:13 bug#52459: 28.0.90; prin1-to-string does not escape bidi control characters despite print-escape-control-characters=t Daniel Mendler
2021-12-12 20:42 ` Eli Zaretskii
2021-12-12 21:11   ` Daniel Mendler
2021-12-12 21:33     ` Daniel Mendler
2021-12-13 12:22       ` Eli Zaretskii
2021-12-13 13:19         ` Daniel Mendler [this message]
2021-12-13 13:30           ` Daniel Mendler
2021-12-13 15:24             ` Eli Zaretskii
2021-12-13 16:32               ` Daniel Mendler
2021-12-13 17:07                 ` Eli Zaretskii
2021-12-13 18:13                   ` Daniel Mendler
2021-12-13 18:28                     ` Eli Zaretskii
2021-12-13 18:35                       ` Daniel Mendler
2021-12-13 18:52                         ` Eli Zaretskii
2021-12-13 18:57                           ` Daniel Mendler
2021-12-13 19:08                             ` Eli Zaretskii
2021-12-13 19:16                               ` Daniel Mendler
2021-12-13 19:38                                 ` Eli Zaretskii
2021-12-14 18:23                                   ` Dmitry Gutov
2021-12-14 18:32                                     ` Daniel Mendler
2021-12-14 18:40                                       ` Dmitry Gutov
2021-12-14 18:47                                       ` Eli Zaretskii
2021-12-14 18:51                                         ` Daniel Mendler
2021-12-14 19:41                                           ` Dmitry Gutov
2021-12-14 19:22                                       ` Andreas Schwab
2021-12-14 18:39                                     ` Eli Zaretskii
2021-12-14 18:56                                       ` Dmitry Gutov
2021-12-14 19:20                                         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0eabc668-ecb2-8f77-17cf-f9cb6dcf0626@daniel-mendler.de \
    --to=mail@daniel-mendler.de \
    --cc=52459@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).