Cc:52459@debbugs.gnu.org
From: Dmitry Gutov<dgutov@yandex.ru>
Date: Tue, 14 Dec 2021 21:23:27 +0300
And, to reiterate once more, I'm against partial solutions that affect
only some functions that produce strings, and don't affect at all any
text displayed from a buffer. It would be a broken solution, because
we will never be able to explain why 'prin1' produces escapes whereas
'format' and 'message' don't.
I just did a little testing, and it seems
'print-escape-control-characters' only affects 'prin1-to-string' and
'prin1' but not 'message' or 'format'.
Is that a problem?
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.
If not, adding a new variable which makes the same distinction seems
consistent with the current design.
The goal is explicitly different, and specifically targets the display
of text to users. And IMO that is not consistent with the current
design, because these variables definitely weren't meant to affect how
text is presented to users. We have other similar features for that,
like nobreak-char-display etc.