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

Previous Next

Full log

Message #77 received at 52459 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, 52459 <at> debbugs.gnu.org
Subject: Re: bug#52459: 28.0.90; prin1-to-string does not escape bidi control
 characters despite print-escape-control-characters=t
Date: Tue, 14 Dec 2021 21:56:16 +0300

On 14.12.2021 21:39, Eli Zaretskii wrote:
>> Cc:52459 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dgutov <at> 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.

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.

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.