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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 52459@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 13 Dec 2021 19:13:32 +0100
> 
> >  1) produce strings for using in program source files.
> >  2) produce strings for display in various UIs
> > 
> > The solutions should IMO be different, because the first is not about
> > displaying these characters, while the second is about displaying
> > them.
> 
> No, they are not different for my purposes since I want to have the
> ability to copy strings from the UI to a source file. Working around the
> problem on the display level (glyphless-display-mode) will preclude this
> use case.

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.

> > For 1), is print-escape-multibyte satisfactory?  If not, why not?
> 
> I already explained this. `print-escape-multibyte` obfuscates the string
> too much, which is undesirable for a debugging UI. Note that I am
> passing on this experience report from a Russian user who observed that
> Marginalia (which currently uses `print-escape-multibyte=t`) produces
> output which is not as helpful as it could be thanks to the escaping of
> all multi byte characters. The escaping hurts users of multi-byte languages.

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?

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.

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

> `print-escape-control-characters` is misleading since it only encodes
> Ascii control characters. Is there anything which prevents the addition
> of a configuration variable `print-escape-unicode-control-characters`,
> which ensures full escaping of *all control characters*

Escaping where? on display?  That won't help you to write strings as
in bidi-directional-controls-chars.  I thought this was one part of
your request?

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.