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

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> I would propose something like the below, which will cause the NUL byte
>> to be rendered as \0 instead of ^@.  We could potentially do this with
>> other control characters too, if they cause trouble too?
>
> Isn't the fact that copying text into the clipboard stops at the first
> null character a Windows-specific issue?  And if it isn't Windows
> specific, isn't it at least specific to selections?

It seems to be application specific.  When I copy to a Firefox text area
on GNU/Linux I get a truncated result, but using xclip | od -c, I can
see the NUL byte and following characters are there.

>
> I think Emacs doesn't need this change for all occurrences of the null
> byte, because Emacs Lisp strings and buffer text will happily DTRT
> with them (they were designed to do so).  So I thin we should only
> "fix" this problem where it happens, not in print functions in
> general.

We could try fixing this in `gui-select-text', but the problem there is
that we don't necessarily know that replace NUL with "\0" is valid.

>
> Exactly.  But if we change print_object like you suggest, there's no
> way of being sure the null bytes won't be mangled by some application
> of a print function.

I'm not sure what you mean.