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 #59 received at 52459 <at> debbugs.gnu.org (full text, mbox):
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.