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

From: Daniel Mendler <[email-masked]>
Date: Mon, 13 Dec 2021 19:57:54 +0100

On 12/13/21 7:52 PM, Eli Zaretskii wrote:
> Not only is it unreasonable, it is simply impossible.  Representing
> characters _on_display_ and writing such a representation into a file,
> as in simple.el, are two different and incompatible goals.  The
> solutions for them must be separate.  I already explained why, and if
> my explanations still don't convince you, then I'm sorry, but I cannot
> help you more than that, because it means we don't have a common
> language and understanding to discuss this stuff.

I produce strings from Elisp values using `prin1-to-string`. These
strings should be escaped such that I can use copy them to source files
as is. Furthermore when I display the string in the UI, the string
should not mess up the display. This requires the string to not have
control characters.

You are seriously misunderstanding what I am proposing.

Please consider my proposal: I propose the addition of a variable
`print-escape-unicode-control-characters` which ensures that
`prin1-to-string` returns a string where all control characters are
escaped. This proposal is certainly not impossible.

Currently `prin1-to-string` produces a string which contains bidi
control characters despite `print-escape-control-characters=t`.

>>>> Once again - I propose the addition of configuration variables which
>>>> configure `prin1-string` to produce output where all control characters
>>>> are escaped.
>>>
>>> That could help in case 1), but not in case 2), because there prin1 is
>>> not used, or not necessarily used.
>>
>> I am only taking about prin1. The issue is about prin1. My goal is to
>> produce safely escaped string representations of Elisp values, including
>> strings and other values.
> 
> 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.