GNU bug report logs - #6991
Please keep bytecode out of *Backtrace* buffers

Previous Next

Full log

Message #121 received at 6991 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, johnw <at> gnu.org, monnier <at> iro.umontreal.ca,
 6991 <at> debbugs.gnu.org, larsi <at> gnus.org, drew.adams <at> oracle.com
Subject: Re: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Sat, 19 Nov 2016 09:39:09 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> I would propose something like the below, which will cause the NUL byte
>> to be rendered as \0 instead of ^@.  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?

It seems to be application specific.  When I copy to a Firefox text area
on GNU/Linux I get a truncated result, but using xclip | od -c, I can
see the NUL byte and following characters are there.

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

We could try fixing this in `gui-select-text', but the problem there is
that we don't necessarily know that replace NUL with "\0" is valid.

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

I'm not sure what you mean.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.