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

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 12 Dec 2021 20:14:01 UTC

Severity: normal

Found in version 28.0.90

Full log


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 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:23:27 +0300
On 13.12.2021 22:38, Eli Zaretskii wrote:
>> To break it down once more:
>>
>> 1. We have the function `prin1-to-string` which can be used to produce a
>> string representation for an Emacs lisp value.
>>
>> 2. The behavior of the function can be adjusted via configuration
>> variables, in particular `print-escape-multibyte` and
>> `print-escape-control-characters`. `print-escape-multibyte` is very
>> aggressive, it escapes every multibyte character.
>> `print-escape-control-characters` only escapes ASCII control characters.
>>
>> 3. I am asking for a way to configure `prin1-to-string` such that it
>> escapes control and other glyphless characters but not all multibyte
>> characters, such that text still stays somewhat readable. I want less
>> aggressive escaping than `print-escape-multibyte`. If I set only
>> `print-escape-control-characters=t` is not sufficient since it escapes
>> only ASCII control characters.
> 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?

If not, adding a new variable which makes the same distinction seems 
consistent with the current design.




This bug report was last modified 3 years and 184 days ago.

Previous Next


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