[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6991: Please keep bytecode out of *Backtrace* buffers
From: |
Drew Adams |
Subject: |
bug#6991: Please keep bytecode out of *Backtrace* buffers |
Date: |
Fri, 26 Feb 2016 17:49:59 -0800 (PST) |
> 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) "\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) "\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