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

[Eli Zaretskii <eliz@gnu.org>]

> From: npostavs@users.sourceforge.net
> Date: Fri, 18 Nov 2016 20:55:54 -0500
> Cc: Juanma Barranquero <lekktu@gmail.com>, Lars Ingebrigtsen <larsi@gnus.org>,
> 	John Wiegley <johnw@gnu.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, 6991@debbugs.gnu.org
> 
> Drew Adams <drew.adams@oracle.com> writes:
> >
> > Here's a backtrace with some byte-code in it:
> >
> > Debugger entered--entering a function:
> > * icicle-ucs-names()
> > * #[(prompt &optional names) "\b\204
> >
> >
> > See, only the top two lines got pasted (even into an Outlook
> > window, and the second line was truncated at the first null
> > byte (it appears as ^@ in the backtrace, where that is a null
> > char and not two chars).
> 
> 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?

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.

> I do think it's worth keeping the bytecode in the backtrace, because
> it's not useless: you can run `disassemble' on it and get something
> meaningful.

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.