bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52459: 28.0.90; prin1-to-string does not escape bidi control charact


From: Dmitry Gutov
Subject: bug#52459: 28.0.90; prin1-to-string does not escape bidi control characters despite print-escape-control-characters=t
Date: Tue, 14 Dec 2021 21:23:27 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 13.12.2021 22:38, Eli Zaretskii wrote:
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.

I just did a little testing, and it seems 'print-escape-control-characters' only affects 'prin1-to-string' and 'prin1' but not 'message' or 'format'.

Is that a problem?

If not, adding a new variable which makes the same distinction seems consistent with the current design.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]