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 7:28 PM, Eli Zaretskii wrote:
> But in the debug UI use-case, you do want to see the text and be able
> to read it, don't you?  Which is why you said you don't want to have
> escapes there, you want to see characters.  Which means that use-case
> is about _displaying_ these characters, not _replacing_ them with
> something else.  And you _cannot_ copy anything that only exists on
> display, because that copies the actual codepoints, not their visual
> representation.

I want to escape *only control characters* not all multi byte characters.

> The use case you describe with Marginalia is of a different kind --
> why do they use print-escape-multibyte in that case?  Cyrillic text
> doesn't use bidi controls, so what does that use case have to do with
> your request?

Of course Cyrillic text is not using bidi but it is still affected by
print-escape-multibyte. If I have a debugging UI I want it to work with
all kinds of languages, rtl and ltr. Multi-byte and single-byte.

> What I'm suggesting is to use print-escape-multibyte when producing
> strings for inclusion in the source code, and only for that purpose.
> You, OTOH, are talking about case 2), where these strings are
> presented in a UI.  Then of course print-escape-multibyte is
> inappropriate for that.

This is not good enough, I want to produce strings which can be copied
to the source and presented in the UI in the same form. I argue that
this is not an unreasonable requirement.

>> 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.

> But I already said that, and so it sounds like we have some grave
> misunderstanding that I'm unable to resolve.  So maybe it's time for
> someone else to try.  Sorry I couldn't be of more help.

Yes. Maybe someone else can chime in with their opinion.