bug#6991: Please keep bytecode out of *Backtrace* buffers

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Tue, 22 Nov 2016 16:07:06 -0500
>> Cc: 6991@debbugs.gnu.org, Juanma Barranquero <lekktu@gmail.com>, John 
>> Wiegley <johnw@gnu.org>, 
>>      Stefan Monnier <monnier@iro.umontreal.ca>, Lars Magne Ingebrigtsen 
>> <larsi@gnus.org>, 
>>      Drew Adams <drew.adams@oracle.com>
>> 
>> > I'm confused: which problem the above is supposed to fix?  Are we
>> > still talking about putting null bytes in selections, or are we
>> > talking about something else?
>> 
>> The original bug report is about copying backtraces containing byte
>> code to other applications (e.g., web browser, mail client, etc). The
>> byte code in backtraces is currently printed with several characters
>> backslash escaped (newline, formfeed, backslash, double quote, and
>> characters higher than 0x80). I propose to extend this escaping to
>> null bytes as well. That will (somewhat indirectly) solve the problem
>> of copying backtraces to other applications, without lossyness (i.e.,
>> (equal (read (print str)) str) remains true). It won't solve the
>> problem of copying arbitrary text containing null bytes to other
>> applications, it only avoids the most common case of the user needing
>> to copy text containing null bytes.
>
> I'm not necessarily opposed, but I never had any problems with binary
> nulls, except when copying to clipboard.

I've never needed to copy binary nulls except when a backtrace had one.

>
>> So in addition to that, your proposal to escape null bytes in xselect
>> and w32select would still be needed to cover the general case. The
>> drawback to replacing nulls in the {x,w32}select code is that the
>> conversion is lossy, and there is a slightly increased chance of the
>> user not noticing there was lossy conversion (relative to the current
>> lossy "conversion" of truncating the string).
>
> Yes, it's lossy, but what other alternative do we have, except losing
> much more?

Yes, there's no perfect solution.  That's why I prefer to solve just the
immediate problem by extending the escaping in `print' to cover null
bytes.  And this will keep working if, for example, we make the general
case of copying null bytes to clipboard use a customizable replacement.