From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#6991: Please keep bytecode out of *Backtrace* buffers Date: Fri, 26 Feb 2016 17:49:59 -0800 (PST) Message-ID: <2223f654-1e67-4a9a-a471-828fd4078410@default> References: <8739tm9vzl.fsf@jidanni.org> <87vb5ct1lz.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1456537886 27723 80.91.229.3 (27 Feb 2016 01:51:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Feb 2016 01:51:26 +0000 (UTC) Cc: Juanma Barranquero , Lars Ingebrigtsen , 6991-done@debbugs.gnu.org, Stefan Monnier , 6991@debbugs.gnu.org To: John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 27 02:51:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZU2K-0001U4-Eo for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Feb 2016 02:51:12 +0100 Original-Received: from localhost ([::1]:52939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZU2J-0007qi-Oi for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 20:51:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZU2F-0007qX-7P for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 20:51:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZU2B-0008N9-7u for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 20:51:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZU2B-0008N4-4E for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 20:51:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZU2A-0005pV-W5 for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 20:51:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Feb 2016 01:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6991 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 6991-done@debbugs.gnu.org id=D6991.145653781322347 (code D ref 6991); Sat, 27 Feb 2016 01:51:02 +0000 Original-Received: (at 6991-done) by debbugs.gnu.org; 27 Feb 2016 01:50:13 +0000 Original-Received: from localhost ([127.0.0.1]:48049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZU1N-0005oJ-3c for submit@debbugs.gnu.org; Fri, 26 Feb 2016 20:50:13 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:27615) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZU1L-0005ny-Oy; Fri, 26 Feb 2016 20:50:12 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1R1o5Bd019684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Feb 2016 01:50:05 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u1R1o41N006274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 27 Feb 2016 01:50:04 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u1R1o0rG021227; Sat, 27 Feb 2016 01:50:03 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113922 Archived-At: > 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) "=08\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) "=08\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-re= cursive-minibuffers completion-ignore-case icicle-ucs-names delq nil mapcar= icicle-make-char-candidate copy-sequence t (1) "=09" ((3 (face icicle-cand= idate-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 icicl= e-transform-multi-completion (2) get-text-property 0 icicle-whole-candidate= characterp error "Invalid character: `%s'" add-to-list icicle-read-char-hi= story icicle-read-char-by-name-multi-completion-flag icicle-show-multi-comp= letion-flag icicle-multi-completing-p icicle-list-use-nth-parts icicle-tran= sform-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)=20 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