[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Sat, 19 Nov 2016 09:41:29 +0200

> From: address@hidden
> Date: Fri, 18 Nov 2016 20:55:54 -0500
> Cc: Juanma Barranquero <address@hidden>, Lars Ingebrigtsen <address@hidden>,
>       John Wiegley <address@hidden>,
>       Stefan Monnier <address@hidden>, address@hidden
> Drew Adams <address@hidden> writes:
> >
> > 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).
> I would propose something like the below, which will cause the NUL byte
> to be rendered as \0 instead of address@hidden  We could potentially do this 
> with
> other control characters too, if they cause trouble too?

Isn't the fact that copying text into the clipboard stops at the first
null character a Windows-specific issue?  And if it isn't Windows
specific, isn't it at least specific to selections?

I think Emacs doesn't need this change for all occurrences of the null
byte, because Emacs Lisp strings and buffer text will happily DTRT
with them (they were designed to do so).  So I thin we should only
"fix" this problem where it happens, not in print functions in

> I do think it's worth keeping the bytecode in the backtrace, because
> it's not useless: you can run `disassemble' on it and get something
> meaningful.

Exactly.  But if we change print_object like you suggest, there's no
way of being sure the null bytes won't be mangled by some application
of a print function.

reply via email to

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