emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#6991: closed (Please keep bytecode out of *Backtra


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#6991: closed (Please keep bytecode out of *Backtrace* buffers)
Date: Fri, 26 Feb 2016 06:43:02 +0000

Your message dated Fri, 26 Feb 2016 17:11:28 +1030
with message-id <address@hidden>
and subject line Re: bug#6991: Please keep bytecode out of *Backtrace* buffers
has caused the debbugs.gnu.org bug report #6991,
regarding Please keep bytecode out of *Backtrace* buffers
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
6991: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6991
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Please keep bytecode out of *Backtrace* buffers Date: Tue, 07 Sep 2010 09:35:10 +0800
Please keep bytecode out of *Backtrace* buffers.
* It is unreadable.
* It will cause problems when sent via email. Even if one runs col(1)
and strings(1) on it, nobody can read it anyway.
* The mountain of gobbledygook makes people reading give up on trying to help.
E.g., http://article.gmane.org/gmane.emacs.w3m/8695



--- End Message ---
--- Begin Message --- Subject: Re: bug#6991: Please keep bytecode out of *Backtrace* buffers Date: Fri, 26 Feb 2016 17:11:28 +1030 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
Stefan Monnier <address@hidden> writes:

> You can try the simple patch below.  It doesn't cut it for me, and
> I think the only way to make it work well would be to change the
> representation of the byte-codes so that they're not just a "unibyte
> string" but an object with a distinctive type: the patch only catches
> the case where the byte-codes appear within a printed
> byte-compiled-function, not when they're arguments to the `byte-code'
> function or to the `make-byte-code' function, and I'm sure there can be
> other cases.

The patch doesn't seem to do what we want.

If we don't have debug-on-error, it's OK:

eval: Wrong number of arguments: #[(&optional handle) "..<bytecode>.." 
[article-buffer handle temp-buffer coding-system-for-read 
coding-system-for-write default-process-coding-system mm-dissect-buffer t 
buffer-name generate-new-buffer ...] 28], 2

But with debug-on-error, the backtrace is as byte-ey as ever:

Debugger entered--Lisp error: (wrong-number-of-arguments #[(&optional handle) 
"p        \204
\306\307!\214``}\210\212        address@hidden  @!\203\245\311\312!r
q\210\313\216\314 \210\315      @!\210\316\317  8       \211@;\203A     @\202E  
A@@)\"\210\320\211B\321      
address@hidden"\211\203}\323\324\307#\211\203}\325=\204}\326\327 \"\330 
\210\331 
\210c\210\332ed\333\324\324\334\335\336\337\340\337\341\342\341\343\341\344\345\346\347-\"\350\346\347.\"\341\351\352\353&\210.*\354
 *\207" [article-buffer handle temp-buffer coding-system-for-read 
coding-system-for-write default-process-coding-system mm-dissect-buffer t 
buffer-name generate-new-buffer " *temp*" #[nil "\301!\205     \302!\207" 
[temp-buffer buffer-name kill-buffer] 2] mm-disable-multibyte 
insert-buffer-substring mm-decode-content-transfer-encoding 2 utf-8 
mail-content-type-get charset mm-charset-to-coding-system nil ascii 
decode-coding-string buffer-string erase-buffer mm-enable-multibyte 
call-process-region "w3m" "-halfdump" "-no-cookie" "-I" "UTF-8" "-O" "-o" 
"ext_halfdump=1" "display_ins_del=2" "pre_conv=1" "-t" format "%s" "-cols" 
"display_image=on" "-T" "text/html" gnus-html-wash-tags tab-width 
gnus-html-frame-width] 28] 2)
  gnus-article-html(1 2)
  eval((gnus-article-html 1 2) nil)
  eval-expression((gnus-article-html 1 2) nil)
  funcall-interactively(eval-expression (gnus-article-html 1 2) nil)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]