bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52459: 28.0.90; prin1-to-string does not escape bidi control charact


From: Eli Zaretskii
Subject: bug#52459: 28.0.90; prin1-to-string does not escape bidi control characters despite print-escape-control-characters=t
Date: Mon, 13 Dec 2021 20:52:08 +0200

> Cc: 52459@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 13 Dec 2021 19:35:37 +0100
> 
> > 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.

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.

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

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

Yes, please.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]