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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
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: bug#6991: Please keep bytecode out of *Backtrace* buffers
Date: Tue, 22 Nov 2016 20:52:53 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 22 Nov 2016 13:07:13 -0500
> Cc: 6991 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>, John Wiegley <johnw <at> gnu.org>, 
> 	Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 
> 	Drew Adams <drew.adams <at> oracle.com>
> 
> On Sun, Nov 20, 2016 at 10:46 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > It just doesn't feel right to me to fix a problem that is specific to
> > selections in a general-purpose low-level facility for printing
> > strings.  Emacs can handle null bytes in strings very well, so I see
> > no need to change the print functions.
> 
> Does the fact that this replacement would only happen when
> `print-escape-nonascii' is non-nil help at all? And the fact that this
> same function already escapes newline, formfeed, and every character
> larger than 0x80 (all of which Emacs can handle in strings too)?
> 
> Can we have both solutions? The selection fix is lossy, so avoiding
> the need for it where possible seems like a good thing to me.

I'm confused: which problem the above is supposed to fix?  Are we
still talking about putting null bytes in selections, or are we
talking about something else?

Previous Next

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