bug#52459: 28.0.90; prin1-to-string does not escape bidi control characters despite print-escape-control-characters=t

[Daniel Mendler]

On 12/13/21 8:08 PM, Eli Zaretskii wrote:
>> Cc: 52459@debbugs.gnu.org
>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Date: Mon, 13 Dec 2021 19:57:54 +0100
>>
>>> Once again: prin1 will not help with displaying these characters.
>>> Emacs doesn't use prin1 to display text.
>>
>> Of course not. I am using prin1 to create a string from a value which I
>> can then copy to a source file or display somewhere in the UI.
> 
> 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.