all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Mendler <mail@daniel-mendler.de>
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 21:38:30 +0200	[thread overview]
Message-ID: <83pmq0l2h5.fsf@gnu.org> (raw)
In-Reply-To: <0491af1e-b57d-c5bd-c17d-b9bc1ef34929@daniel-mendler.de> (message from Daniel Mendler on Mon, 13 Dec 2021 20:16:54 +0100)

> Cc: 52459@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 13 Dec 2021 20:16:54 +0100
> 
> > That will solve only a small fraction of situations where these
> > characters are displayed, because the vast majority of them don't use
> > prin1 to produce a string to display.  Most of the stuff displayed by
> > Emacs doesn't come from strings produced by prin1, it comes from
> > displaying the text of some buffer.
> 
> Yes, it solves a small fraction of situations. This issue does not
> address a generic setting, it only addresses the behavior of `prin1`. As
> I described at length there are packages which are affected by this and
> which could improve from an improvement of `prin1`.
> 
> To break it down once more:
> 
> 1. We have the function `prin1-to-string` which can be used to produce a
> string representation for an Emacs lisp value.
> 
> 2. The behavior of the function can be adjusted via configuration
> variables, in particular `print-escape-multibyte` and
> `print-escape-control-characters`. `print-escape-multibyte` is very
> aggressive, it escapes every multibyte character.
> `print-escape-control-characters` only escapes ASCII control characters.
> 
> 3. I am asking for a way to configure `prin1-to-string` such that it
> escapes control and other glyphless characters but not all multibyte
> characters, such that text still stays somewhat readable. I want less
> aggressive escaping than `print-escape-multibyte`. If I set only
> `print-escape-control-characters=t` is not sufficient since it escapes
> only ASCII control characters.

And, to reiterate once more, I'm against partial solutions that affect
only some functions that produce strings, and don't affect at all any
text displayed from a buffer.  It would be a broken solution, because
we will never be able to explain why 'prin1' produces escapes whereas
'format' and 'message' don't.  It is unreasonable to require Lisp
programs which will want to use something like that to use only
'prin1' and not the other functions routinely used for producing text
for display.





  reply	other threads:[~2021-12-13 19:38 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
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 [this message]
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

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

  git send-email \
    --in-reply-to=83pmq0l2h5.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=52459@debbugs.gnu.org \
    --cc=mail@daniel-mendler.de \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.