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

[Eli Zaretskii]

> Cc: 52459@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 13 Dec 2021 17:32:40 +0100
> 
> On 12/13/21 4:24 PM, Eli Zaretskii wrote:
> > So you want a feature that would produce strings suitable for using in
> > program source files, like we did in the above example?  Is that the
> > meaning of "sanitize" you have been using?
> > 
> > Are there other use cases for those "escaped" or "sanitized" strings?
> > If so, please describe them as well.
> 
> As you said the use case is to produce strings suitable in source files
> or strings in a form which looks like strings occurring in source files.
> This use case appears in debuggers and other UIs which inspect variable
> values at Emacs runtime. Furthermore code editing and refactoring tools
>  produce strings which are supposed to be used directly in source files.
> 
> For the usage of strings in source files on could simply use
> `print-escape-multibyte=t` however in particular in debugger UIs this
> leads to a severe obfuscation of the output, which in particular hurts
> users wo use Emacs in a setup with a multi-byte bidi language, Hebrew,
> Arabic, Chinese, etc. Therefore in debugger UIs I only want to escape
> control characters but not other multi-byte display characters.

So there are two different use cases:

 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.

For 1), is print-escape-multibyte satisfactory?  If not, why not?

For 2), we now have in Emacs 29 the glyphless-display-mode, whereby
the bidi control characters are shown as small boxes with their
acronyms (RLE, FSI, PDI, etc.).  Is that satisfactory?  If not, why
not?