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

[Drew Adams <drew.adams@oracle.com>]

> Drew, can you show me what it will look like to have the elision
> performed? Sometimes the byte-code contains strings that give me
> a clue as to the problem, so I'm wondering what will disappear if
> this is fixed.

Nothing prevents letting a user control the degree of elision.
If someone thinks that part of a #[...] occurrence might be
helpful then a yankable and readable part of it could be included.
In general, my guess is that most #[...] occurrences can just
be removed (replaced by an elision indicator).

I can show what I do, at least:

1. I start by trying to yank a whole backtrace into a bug-report
   buffer.

2. That typically doesn't work completely: some of the yanked
   text is truncated (not yanked) because it is binary stuff
   from byte-code.

3. So I often have to yank separate pieces of a backtrace - parts
   that are yankable (which might still contain some byte-code,
   but byte-code that is yankable).

4. I remove anything that is problematic/meaningless, leaving
   ordinary text that humans can read.  In my experience there
   is nothing in the byte code that is of interest and that
   doesn't also appear anyway in the non-byte-code part of the
   backtrace.

5. I can include some from an Emacs 24.5 backtrace (Emacs 25 is
   unusable for me - crashes within a minute or two, and has
   done so for a couple years now).

6. Caveat: I byte-compile my code with the oldest Emacs version
   that that particular code supports.  That could be Emacs 20,
   22, 23 (or maybe 24 or 25, for some libraries).

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).

The " \204 that you (might) see here looks like this in Emacs:
"^H\204^G^@\306" etc., but each of those ^LETTER occurrences
is a control char, not a doublet with first char ^.

Then I would yank a bit more, not bothering to copy the
same byte-code that appears in the third line:

* apply(#[(prompt &optional names) "\b\204


Then I would copy and paste some more - in this case all of
the rest of the backtrace has no byte-code:

* read-char-by-name("Unicode (name or hex): ")
  (list (read-char-by-name "Unicode (name or hex): ") (prefix-numeric-value current-prefix-arg) t t)
  call-interactively(ucsc-insert nil nil)
  command-execute(ucsc-insert)

Then I would clean up the byte-code that was successfully
yanked, probably replacing it with "...".  I don't have a
special way of doing these things.  I just edit manually,
to give something like this:

Debugger entered--entering a function:
* icicle-ucs-names()
* #[(prompt &optional names) "..." [names cands prompt new-prompt enable-recursive-minibuffers completion-ignore-case icicle-ucs-names delq nil mapcar icicle-make-char-candidate copy-sequence t (1) "	" ((3 (face icicle-candidate-part))) icicle-mctize-all lambda (string pred action) if (eq action (quote metadata)) (quote (metadata (category . unicode-name))) complete-with-action action quote (string pred) completing-read string-match-p "\\`[0-9a-fA-F]+\\'" string-to-number 16 "^#" read assoc-string try-completion icicle-transform-multi-completion (2) get-text-property 0 icicle-whole-candidate characterp error "Invalid character: `%s'" add-to-list icicle-read-char-history icicle-read-char-by-name-multi-completion-flag icicle-show-multi-completion-flag icicle-multi-completing-p icicle-list-use-nth-parts icicle-transform-before-sort-p ...] 10 "Read a character... I'VE ELIDED MOST OF A LONG DOC STRING HERE")
* apply(#[(prompt &optional names) - same as line above.)
* read-char-by-name("Unicode (name or hex): ")
  (list (read-char-by-name "Unicode (name or hex): ") (prefix-numeric-value current-prefix-arg) t t)
  call-interactively(ucsc-insert nil nil)
  command-execute(ucsc-insert) 

In this case I also manually elided a long doc string, not
just byte-code.

Is it worthwhile to keep some of what is inside #[...]?
Here, I did - I removed only the binary code stuff.  But it
might be good in most cases to just elide each occurrence of
#[STUFF].

HTH - Drew