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: mail@daniel-mendler.de, 52459@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 14 Dec 2021 21:56:16 +0300
> 
> > It could be.  I guess the only reason no one complained about it is
> > that those print functions are used in very specialized cases.  But in
> > this case, the requirement was to use it for displaying human-readable
> > text in a UI, and I think in that context it would be highly
> > surprising, to say the least, to have it supported by prin1, but not
> > by formatted printing APIs.
> 
> I'm not sure it would be a problem if 'message' and 'format' also honor 
> that new variable. Aside from inconsistency with existing vars, that is.

We agree.  But that is not what is being requested by Daniel.

> It seems to me that you misunderstand the use case, or at least the 
> approach that Daniel wants to take:
> 
> Helpful, or Help buffers used by commands like 'describe-variable', use 
> prin1 to output values which are not known in advance (like the value of 
> the described variable).
> 
> And the dynamic vars under discussion can make those printed values more 
> predictable and easier to grok (and copy-paste, and etc).

The set of use cases that was described included more than just
Helpful.  It explicitly included displaying text not known in advance,
such as in debugging UI, where one needs to display strings that come
from the program being debugged.

Hoever, you may be right that I have no good understanding of the use
cases.  I did try to understand them, but found it to be impossible,
because every question I tried to ask, every concept of a solution I
tried to propose was inevitably met with the equivalent of "why won't
you give me my variable".  I actually think that there are two
distinct classes of use cases involved, but Daniel rejected that,
insisting, AFAIU, that all the use cases are the same and need a
single solution.  Which I think is based on the wrong mental model of
how the related stuff works in Emacs.

So I'm sorry, but I cannot be of help in this discussion under those
terms.  That is not the way I'm used to approach a problem.