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

[npostavs]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> FWIW, I agree.  The only issue I can see here is that depending on how
> it's done, it could affect the size of the .elc files (by using two bytes
> per bytecode 0 rather than 1).  Nothing too terrible, but it's probably
> worth checking whether it does make such a difference and if so how serious
> it is.

On average it increases Emacs' .elc by ~200 bytes each, 276kB in total,
or 100.62%.

elc-sizes.org.gz
Description: table of size changes for print NUL as \0

But actually, while looking at this, I understood more about what the
print_escape_nonascii flag is used for (i.e., multibyte vs unibyte
stuff), and I no longer think it makes sense for it to affect printing
the NUL byte anyway.

I propose adding a new flag print_escape_control_characters instead (see
patch #3 in the series).  I also implemented hiding the byte code
functions with text properties in #4.  It's not quite satisfactory
though, because it doesn't cover byte code functions values that are
arguments, only byte code being called.  I think printing needs to be
made more flexible in order to cleanly catch all byte code values.
Patch #5 replaces NUL bytes with "\0" in X selections (I guess it covers
w32 as well? Haven't checked yet).

backtrace-6991-screenshot.png
Description: screenshot

v1-0001-Operate-on-frame-list-instead-of-printed-backtrac.patch
Description: patch

v1-0002-Improve-ert-backtrace-recording.patch
Description: patch

v1-0003-Escape-control-characters-in-backtraces-Bug-6991.patch
Description: patch

v1-0004-Hide-byte-code-in-backtraces-Bug-6991.patch
Description: patch

v1-0005-Escape-NUL-bytes-in-X-selections-Bug-6991.patch
Description: patch